Stil spørgsmål, der kan besvares med beviser
Et virksomhedsgodkendelsesspørgeskema bør forbinde forretningskrav med understøttet adfærd, driftsansvar og acceptbevis. En lang liste af ja-eller-nej-spørgsmål kan skjule vigtige begrænsninger: en leverandør kan understøtte en bred kategori, mens den ikke understøtter den specifikke lejer, livscyklus eller implementeringsadfærd, som køberen har brug for. Spørgeskemaet bør derfor spørge, hvad der understøttes, under hvilken konfiguration, hvem der driver det, og hvordan svaret kan verificeres.
Denne artikel foreslår en spørgeskemastruktur og angiver ikke, at EmailAuth implementerer nogen anført kapacitet. Ingen leverandør blev kontaktet, og der blev ikke indhentet svar på spørgeskemaet. Microsofts vejledning om fælles ansvar og Azures identitetsvejledning til flere lejere give officielle eksempler på forskelle, der betyder noget, men de kan ikke erstatte aktuelle beviser fra det produkt, der vurderes.
Start med omfang og beslutningsejerskab
Registrer den foreslåede kundepopulation, domæner, afsendelsesarbejdsgange, implementeringsmulighed, nødvendige integrationer og påtænkte administratorer. Identificer, hvilke krav der er obligatoriske, hvilke der er præferencer, og hvilke der kræver en kvalificeret juridisk, sikkerheds- eller kommerciel anmelder. Et spørgeskema uden et defineret omfang kan give svar, der er teknisk sande for en anden udgave eller et andet miljø. Bevar produktversionen og tilbud reference ved siden af hvert svar.
Bed leverandøren om at skelne mellem implementeret support, konfigurationsafhængig support, planlagt arbejde og ikke-understøttede krav. Gør ikke en køreplansdato til aktuel kapacitet. Hvor et svar afhænger af en anden tjeneste, skal du identificere denne afhængighed og den ansvarlige part. Køber bør også dokumentere sine egne forpligtelser; en leverandør kan ikke demonstrere en komplet arbejdsgang, hvis påkrævet kunde DNS , identitet eller adgangsbeslutninger forbliver udefinerede.
Dæk identitet, roller og lejergrænser
Spørg, hvordan brugere autentificerer, hvordan identiteter er bundet til lejere, og hvordan tilladelser tildeles domæner, rapporter, eksporter og administrative operationer. Azures identitetsvejledning adskiller godkendelse fra rollebaseret eller ressourcebaseret godkendelse og kommercielle rettigheder. Afspejle disse forskelle i separate spørgsmål. En erklæring om, at SSO understøttes, etablerer ikke kundeisolation eller effekten af en rollereduktion på en eksisterende session.
Inkluder spørgsmål om serviceidentiteter, brugerlivscyklus, leverandørsupportadgang og revisionsbevis. Kræv en aktuel forklaring af deaktiverings- og tilbagekaldelsesadfærd i stedet for at antage, at en klargøringsintegration håndterer enhver adgangssti. Bed om autoriserede syntetiske negative test, der viser, at en lejer ikke kan læse, eksportere eller ændre en anden lejers ressourcer. Et produktskærmbillede eller rolleliste alene giver ikke dette bevis.
Spørg, hvordan autentificeringsobservationer opnås
Dokumenter hvilke kilder platformen indtager, hvordan deres dækning er beskrevet, og hvordan ikke-understøttede eller manglende observationer er repræsenteret. RFC 9990 definerer DMARC aggregeret rapportering, som har sin egen rapport-opdagelse og leveringsproces. En platforms evne til at parse rapporter garanterer ikke, at hver modtager sender dem, eller at enhver legitim afsender er repræsenteret i en periode.
Spørg, hvordan produktet bevarer den originale rapports herkomst, håndterer dubletter og forklarer fortolkningsgrænser. Hvis den kombinerer udbyderleveringshændelser med godkendelsesrapporter, skal du spørge, hvilke identifikatorer der tillader kobling, og om konklusionerne er på meddelelsesniveau eller streamniveau. Anmod ikke om en universel leveringsgaranti fra autentificeringsdata. Spørgeskemaet bør synliggøre produktets observationsgrænser i stedet for at opmuntre til ikke-underbyggede påstande om fuldstændig dækning.
Tydeliggør implementerings- og driftsansvar
Spørg, hvilke implementeringsmuligheder der i øjeblikket understøttes, og hvad hver enkelt omfatter. Definer, hvem der patcher infrastruktur, opdaterer applikationen, administrerer identiteter, overvåger indtagelse, udfører gendannelse og håndterer hændelser. Microsofts delt ansvarsramme illustrerer, hvorfor forpligtelser varierer fra servicemodel, men den faktiske leverandør skal levere sin egen understøttede tildeling. Et svar markeret som delt skal beskrive ejeren af overleveringen og bekræftelsen, ikke blot dele et afkrydsningsfelt mellem to parter.
For private eller dedikerede muligheder, spørg om netværksstier, datahåndtering, supportadgang og eksterne afhængigheder separat. Udled ikke isolation fra et arkitekturmærke. Kræv dokumentation for de relevante grænser og gennemsigtige arbejdsbyrdeantagelser for dimensionering. Selve spørgeskemaet bør ikke godkende en implementering, firewallændring eller dataoverførsel; disse handlinger kræver særskilt godkendt implementeringsarbejde.
Inkluder krav til datahåndtering og revision
Spørg, hvilke data der opbevares, hvor understøttede konfigurationer placerer dem, hvem der har adgang til dem, og hvordan opbevaring, sletning og eksport fungerer. Skelne primære data, logfiler, sikkerhedskopier og supportartefakter. Denne artikel foretager ikke en juridisk overholdelsesbeslutning eller hævder en leverandørs bopælsadfærd. Den relevante kvalificerede ejer bør gennemgå kontraktmæssige og lovmæssige krav ved hjælp af aktuelle beviser.
For revisionsmæssighed skal du spørge, hvilke handlinger der registreres, om afviste forsøg er inkluderet, hvordan skuespiller- og lejerkontekst er repræsenteret, og hvem der kan eksportere eller ændre opbevaringsindstillinger. Microsoft Entra audit-log dokumentation er et eksempel på en officiel aktivitetslogbeskrivelse, ikke bevis for et andet produkts dækning. Kræv produktspecifikke prøver og grænser i stedet for at acceptere ordet revision som et komplet svar.
Gør arbejdsbyrde og kommercielle antagelser gennemsigtige
Angiv de forventede domæner, lejere, brugere, rapportvolumen, fastholdelse og integrationskadence ved hjælp af godkendte organisatoriske input. Marker estimater og ukendte tydeligt. En delvis måned med observationer understøtter muligvis ikke en nøjagtig forudsigelse af årlig arbejdsbelastning. Spørg leverandøren, hvilke variabler der påvirker tilbuddet, og hvordan ændringer tælles, men udled ikke priser eller pakkeoptagelser fra teknisk dokumentation.
Hold kommerciel inklusion adskilt fra teknisk accept. En funktion kan være inkluderet i et tilbud, men kræver stadig konfiguration og dokumentation; en demonstreret funktion kan være uden for den foreslåede pakke. Registrer kun tilbudsgyldighed, omfang og udelukkelser, når der findes et godkendt tilbud. Ingen pris, rabat, omkostningsmodel eller indkøbsanbefaling er produceret af dette manuskript.
Et krav-og-bevis arbejdsark
Opret kolonner for krav, forretningsgrund, prioritet, understøttet konfiguration, leverandørsvar, beviskilde, anmelder, accepttest, begrænsning og beslutning. Tilføj et antagelsesregister med input, kilde, dato, tillid og effekt, hvis det er forkert. Knyt hvert obligatorisk krav til et konkret beviselement i stedet for en bred markedsføringsside. Behold ubesvarede spørgsmål som huller i stedet for at tolke stilhed som støtte.
For testbare kontroller, beskriv den autoriserede armatur og det forventede resultat. For kontraktlige forpligtelser skal du identificere den relevante godkendte aftale. For driftsansvar, identificer den navngivne ejer og overdragelse. Disse bevistyper kan supplere hinanden, men bør ikke erstattes vilkårligt. En kontrakt kan tildele ansvar uden at demonstrere en teknisk test; en vellykket test kan vise adfærd uden at skabe et støtteforpligtelse.
Fiktiv diagnose: et fuldstændigt udseende spørgeskema
En fiktiv køber modtager bekræftende svar for SSO, eksport, privat implementering og revisionslogfiler. Gennemgangen markerer i første omgang, at spørgeskemaet er afsluttet. En anden anmelder spørger, hvilken udgave der understøtter disse funktioner, om eksport bevarer lejergrænser, og hvad der sker med en aktiv session efter deaktivering. De originale svar løser ikke disse spørgsmål, fordi de beskriver kategorier snarere end resultater.
Det foreslåede svar er at anmode om omfangsmæssig dokumentation og lade de berørte krav stå åbne, indtil de er gennemgået. Køber behøver ikke at anklage leverandøren for urigtige oplysninger; spørgeskemaet kan simpelthen have været for vagt. Dette scenarie er fiktivt og beskriver ikke nogen faktisk leverandørrespons eller produktgab. Ingen ekstern kommunikation eller test blev udført.
Offentliggør hullerne med anbefalingen
En nyttig vurdering identificerer understøttede krav, accepterede begrænsninger, uafklarede beviser og arbejdsbyrdeantagelser, der kan ændre beslutningen. Den skal kunne læses af både tekniske ejere og virksomhedsejere uden at bryde deres forskellige ansvarsområder sammen. Undgå en numerisk score, der indebærer præcision ud over beviserne, medmindre dens metode og begrænsninger udtrykkeligt er godkendt.
Kataloget kræver en krav- og bevismatrix og gennemsigtige arbejdsbyrde eller omkostningsantagelser. Disse originale artefakter forbliver åbne. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast giver en ramme og fiktiv øvelse, ikke gennemført leverandørdue diligence eller en påstand om EmailAuth kapaciteter.