03.05.04 Replay-resistant authentication: requirements and evidence

What replay-resistant authentication under 03.05.04 requires in practice

03.05.04 requires you to implement authentication mechanisms that resist replay for access to both privileged and non-privileged accounts. In plain terms, an attacker who records a valid login exchange must not be able to play it back later and get in. If your contract or CMMC scope requires NIST SP 800-171, you need to show that your sign-in methods meet this test everywhere a user or account authenticates to a system with CUI, not only on the main portal. NIST's discussion for this requirement describes the goal as making it impractical to succeed by recording or replaying earlier authentication messages, and points to protocols that use nonces or challenges, such as time-synchronous or challenge-response one-time authenticators. The control behind the requirement is IA-2(8) from SP 800-53 Rev. 5, which is useful to know when your assessor asks where the expectation comes from.

The hard part is rarely the modern identity provider. It is the legacy application that accepts a static password over a basic form, the service account that authenticates with a long-lived token, and the directory that holds some identities in one store and some in another. Each of these paths must be inventoried and either moved to a replay-resistant method or documented with a compensating arrangement your assessor will accept. Confirm with your assessor how they will treat paths you cannot change. For context, the change analysis from Rev. 2 to Rev. 3 traces this requirement to Rev. 2 requirement 3.5.4 and classifies the change as editorial only, so CMMC Level 2 assessors working from Rev. 2 are testing the same expectation.

SP 800-171A Rev. 3 assesses 03.05.04 with two determination statements, using examine, interview and test methods. Expect the examine work to cover identification and authentication policy, system design documentation, audit records and configuration settings. Interviews will target the staff who run system operations and account management. Testing will look at the mechanisms that support replay resistance. Prepare a list of every authentication path, its mechanism and its owner before the assessment starts, and confirm with your assessor whether they expect you to demonstrate the test method live or with captured evidence.

Which systems and accounts fall under the replay-resistance requirement

Replay resistance applies wherever a user or administrator proves identity to a system that handles CUI, so scoping starts with the places that accept those proofs. The cards below cover the identity layer, access paths, privileged accounts and the legacy or third-party services that often fall outside the obvious inventory.

Identity providers that issue sign-in assertions

Every identity provider that vouches for users to CUI systems is in scope, because the authentication exchange it runs is what must resist replay. Include the self-hosted provider, any directory it reads from, and the protocols it speaks, such as OAuth2, OpenID Connect, SAML, LDAP or RADIUS. Confirm for each protocol whether the sign-in exchange uses a nonce, challenge or time-synchronous factor, and document the answer in the system security plan. A provider that only sends static bearer credentials needs a remediation path before assessment.

VPN and remote access gateways

VPN concentrators, zero trust access proxies and remote desktop gateways are common entry points for CUI and often run their own login flows. Scope every gateway that carries traffic to a CUI boundary, including any fallback path that accepts a password when the preferred factor is unavailable. Check whether the gateway accepts one-time codes that a recorded session could reuse, and whether it binds sign-in to a challenge. Remote and hybrid work patterns usually multiply these gateways, so the inventory should come from network records rather than memory.

Administrative consoles and management interfaces

Hypervisor consoles, cloud management portals, database administration tools, firewall managers and infrastructure dashboards are where privileged accounts act. Each one that can reach a system holding CUI is in scope, even when it sits on a management network. Ask whether each console delegates sign-in to the central provider or keeps local accounts, and whether local accounts are limited to break-glass use with replay-resistant authenticators. Consoles with separate login pages are the most frequent gap in an inventory built from application lists.

Privileged accounts and their sign-in paths

Privileged accounts include system administrators, database owners, security tool operators, and service accounts that a person can use interactively. Each one needs a defined sign-in path, and the requirement covers both privileged and non-privileged accounts, so scope the full population rather than only administrators. Record which accounts can log in directly, which use a jump host, and which hold standing rather than just-in-time access. An administrator who signs in with a reusable password through a separate path is an exception the assessor will ask about.

SSO paths and federated applications

Single sign-on hubs and each application that federates to them form a chain, and an assessor will test the weakest link in it. List every application that processes or accesses CUI, including those that accept a direct username and password alongside federation. Verify whether the federation is enforced or optional, since a fallback login form can bypass the replay-resistant factor. Kerberos-based single sign-on for Linux and UNIX estates is a separate path to record, because ticket exchange has its own replay characteristics.

Third-party and cloud identity services

Hosted identity services, cloud directories and software as a service applications that store or process CUI are in scope even when another company operates them. Ask each provider for its authentication design, which factors it supports, and whether replay-resistant mechanisms are enabled for your tenant rather than only available. Contract terms should state who configures the factors, who holds the audit records and how a change to the default settings is reviewed. Where the provider's default configuration does not enforce a second factor, record that as a configured setting that your team must confirm.

Legacy applications that cannot use modern protocols

Older applications may accept only basic credentials, cannot speak OAuth2, OpenID Connect or SAML, or need a client that cannot be updated. These systems are in scope when they hold CUI, and they are often the hardest part of the replay-resistance work. Options include placing them behind a proxy provider that performs the replay-resistant sign-in, isolating them in an enclave, or documenting a planned replacement with a plan of action and milestones. Each option needs evidence that the chosen control was tested, and an unresolved legacy application should be discussed with the assessor before the assessment date.

How an assessor tests 03.05.04 under SP 800-171A Rev. 3

This table maps how SP 800-171A Rev. 3 assesses 03.05.04 across the examine, interview and test methods, and what each method looks at in your environment. Read it as a checklist of what to prepare before an assessor arrives. The main takeaway is that the test method looks at the replay-resistance mechanism itself, so an assessor will check that every path to privileged and non-privileged accounts uses it.

Assessment method	Objects the assessor looks at	Evidence to prepare	Where it usually fails
Examine (determination statements)	Identification and authentication policy and procedures, system design documentation, system audit records, system configuration settings	Written authentication policy stating which account types must use replay-resistant mechanisms, design diagrams of login flows, configuration exports from the identity provider	Policy says replay resistance is required, but design documents do not show which login paths use it
Interview	Personnel with system operations responsibilities, personnel with account management responsibilities	Named owners for the identity platform, a walkthrough of how new applications are onboarded to the provider, and records of who approves authentication method changes	Operations staff describe challenge-based login from memory, while configuration shows a password-only fallback they did not mention
Test (mechanisms for replay-resistance)	Mechanisms that support or implement identification and authentication capabilities, mechanisms that support or implement replay-resistance	Test results showing that a captured authentication exchange cannot be reused, documented challenge or nonce behavior, and one-time code validity rules	Replay resistance is enabled for the main portal but not for the admin console, API token endpoint or legacy protocol bindings
Examine (audit records)	System audit records covering authentication events	Sample authentication logs showing challenge issuance and one-time code use, with timestamps and account identifiers	Logs record successful logins but not the challenge or code events that show the mechanism operating
Test scope for privileged and non-privileged accounts	Access paths for administrators and standard users, including directory, single sign-on and remote access	Inventory of account types mapped to the authentication method each one uses, reviewed against the system security plan	Privileged accounts use hardware-backed challenge login, but service or break-glass accounts still accept a static password
Determination statement check (documented method)	Whether the organization has defined and implemented the replay-resistance mechanism for the scoped systems	A signed statement of scope, a list of systems in boundary, and the configuration baseline used for each	Scope in the system security plan does not match the systems the assessor sees in the network
Owner confirmation (illustrative)	Assessor questions about the mechanism's configuration after a password reset or account recovery	Runbook showing that recovery flows also enforce the same replay-resistant method	Recovery email link or SMS code bypasses the challenge-based login entirely

The order to implement replay-resistant authentication

The sequence below moves from knowing every path into a CUI system to a tested, documented configuration that resists replay of recorded authentication messages. Each step produces an artifact that the next step depends on, so an assessor can trace a requirement from the policy down to the test result.

Inventory every authentication path to CUI systems
Start by listing every way a person, service or process can authenticate to a system that stores, processes or transmits CUI. Include the console, SSH and remote desktop access, APIs, VPN and remote access gateways, service accounts, break-glass accounts and vendor or maintenance access. The engineering or identity team owns this work, with input from system owners. The output is an authentication path register that names each path, the account types it serves, whether the account is privileged, and the system of record for it. The step is done when a system owner confirms the register matches the system security plan boundary.
Classify each path by replay resistance
For each entry in the register, record the authentication mechanism and determine whether a recorded authentication message could be captured and reused to gain access. Passwords sent over an unprotected channel, static bearer tokens and fixed shared secrets generally fail this test, while challenge-response protocols, nonce-based exchanges and time-synchronous one-time authenticators are the kind of mechanism NIST describes as resisting replay. Document the reasoning for each classification, not only the label. The output is a classified register with a short justification per path, reviewed by the security engineer who will own the assessment evidence.
Select the mechanism for each path
For every path classified as weak or uncertain, choose a replacement mechanism that the identity provider and the target system can support. Options that open-source platforms can provide include OpenID Connect or SAML flows through an identity provider, passkeys and WebAuthn, and TOTP or HOTP one-time passwords. Confirm each choice against the vendor documentation for the exact version you deploy, because support for specific protocols and authenticator types varies. The output is a mechanism decision record for each path, approved by the system owner and linked to the register.
Configure the identity provider and MFA policies
Configure the chosen identity provider, such as authentik, Keycloak, Zitadel or FreeIPA with Kerberos, so that applications delegate sign-in to it and the required second factor is enforced for each account class. Set one-time password and WebAuthn policies, require privileged accounts to use the stronger mechanisms, and disable fallback methods that bypass them. Keep the configuration in version control so changes are recorded. The output is a tested configuration baseline with exported settings, screenshots or configuration files that show each policy, and a list of the applications connected to each provider.
Close or compensate for exceptions
Some legacy systems, embedded devices or vendor appliances may not support a replay-resistant mechanism. For each exception, decide whether to replace the system, place it behind an access layer that enforces a compliant mechanism, or accept the risk through a documented plan of action with an owner and a review date. Confirm with the contracting or compliance lead how the organization records accepted risk in its system security plan. The output is an exception register where every open path has a compensating control, a named owner and a closure decision.
Test the mechanisms and document the results
Test each path against the expected behavior. Confirm that a captured authentication exchange cannot be replayed to gain a session, that privileged and non-privileged accounts both require the chosen mechanism, and that fallback paths are blocked. Where a tester or assessor will verify the result, prepare the examine objects (policies, procedures, design documentation, audit records and configuration settings) and brief the personnel who will answer interview questions. The output is a test record for each path, the updated system security plan section, and an evidence package that maps each result to the assessment determination statements in NIST SP 800-171A Rev. 3. An independent assessor, not the implementation team, issues any assessment conclusion.

Evidence that shows replay resistance and how to keep it current

An assessor testing 03.05.04 looks for proof that replay-resistant mechanisms are configured, designed in, tested and logged in use. The six artifacts below connect configuration, design, testing and operation, so each one should be refreshed on a schedule that matches the system's change rate, not only when an assessment is scheduled.

Identity provider configuration exports

Export the MFA, one-time password and WebAuthn settings from each identity provider that handles privileged or non-privileged sign-in. In Keycloak, check the one-time password policy and WebAuthn settings. In Zitadel, check the login policy and whether Force MFA applies to all users or only local accounts. Store the exports with a date and the change ticket that approved them. Re-export after every change to login policy, and compare against the previous export to catch drift.

Authentication path register

Maintain a register listing every path a user or service can use to authenticate to CUI systems, such as the web console, SSH, VPN, API tokens and legacy LDAP binds. For each path, record whether it uses a nonce or challenge-based factor and which provider enforces it. Any path that accepts a static, reusable credential without a challenge needs a documented justification or a remediation date. Review the register whenever an application is onboarded or a protocol is enabled.

System design documentation

Document how the identity architecture prevents replay: which protocols carry authentication messages, where challenges or nonces are generated, and how time-synchronized one-time codes are validated. Assessors use this to judge whether replay resistance was designed in rather than assumed. Update the diagrams and the system security plan when the identity provider, federation trust or proxy layer changes, and record the version and reviewer on each revision.

Configuration baselines

Keep a baseline for each identity component that states the approved authentication settings, such as enabled factors, disallowed legacy methods and token lifetimes. Compare live configuration against the baseline on a recurring schedule using configuration management tooling or scripted exports, and log each deviation with a disposition. Baselines should be stored under version control so the history of approved changes can be produced for an assessor.

Replay attempt test records

Record tests that try to reuse a captured authentication response, replay an expired one-time code, and submit a previously used challenge response. Each test record should state the target account type (privileged or non-privileged), the expected result, the observed result and the tester. Repeat the tests after identity provider upgrades or protocol changes. Testing can be performed by the organization's staff or by an independent security tester, and the test plan should be approved before execution.

Authentication event audit logs

Retain logs of authentication events, including failed one-time code submissions, rejected challenge responses and MFA enrollment changes, and confirm that they reach the central log store. Assessors use them to see that replay attempts are detected and that accounts are reviewed. Confirm retention periods with the assessor and the contract owner, because the required period is not set by this requirement alone. Sample the logs periodically to verify that the fields needed to identify the account, time and source are present.

Which self-hosted open-source identity tools support replay resistance

authentik acts as an identity provider that applications delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Because it sits in front of many applications, it is the place where replay-resistant sign-in can be enforced once and inherited by connected systems, provided each application is actually routed through it. The project is licensed under the MIT licence, which is permissive and generally low friction for internal use, but the licence does not decide whether a deployment meets 03.05.04.

Protocol coverage: Check which connected applications authenticate through an authentik provider and which still use local accounts or direct LDAP binds that bypass it.
Second factors: Confirm in the authentication flow settings which factor types are enabled and whether nonce or challenge-based methods are required for privileged users.
Proxy providers: Applications without native federation depend on proxy providers, so review how those sessions are established and protected.
Licence review: Have legal confirm the MIT terms fit your distribution and support model.
Evidence: Export flow and policy configuration and access logs showing which sign-in paths were used.

Before relying on authentik, confirm with the vendor and in your own environment which factor types are available in your version, and test that a recorded authentication message cannot be replayed against each protected application.

What meeting 03.05.04 costs in money and effort

Most of the cost of 03.05.04 sits in the identity work, not in a line item called replay resistance. The organization pays for the identity provider, whether that is a licensed product or a self-hosted open-source platform such as authentik, Keycloak, FreeIPA or Zitadel, and for the engineering time to move each application onto it. Self-hosting removes the licence fee but moves the cost to staff who must run, patch, back up and monitor the service inside your own infrastructure. Authenticators are a separate cost: if challenge-response or time-synchronous one-time authenticators are chosen, the organization buys hardware tokens or confirms that its chosen app-based or passkey method meets the replay-resistance test. Ask the vendor or your own team to confirm which authenticator types the chosen platform supports before pricing any hardware.

Costs split into one-time and recurring. One-time costs include the design of the authentication architecture, the migration of applications and service accounts that still accept static passwords or replayable tokens, testing of the new flows, and the initial authenticator rollout. Recurring costs include licences or support contracts, hosting and on-call time, replacement of lost or failed hardware authenticators, and the evidence upkeep that an assessor will sample: configuration exports, change records, and audit logs showing that replay-resistant mechanisms are enforced for privileged and non-privileged accounts. The number of applications, the number of legacy integrations that cannot speak modern protocols, and the size of the user population are the main drivers. Each legacy system that needs a proxy or a separate control increases both the one-time and the recurring effort.

External testing and assessor sampling add cost at the end of the cycle. Assessors test 03.05.04 with the test method as well as examination and interviews, so you should expect to demonstrate the mechanism working, not just describe it. Penetration testing of authentication flows, including attempts to replay captured messages, can be scoped as a fixed-scope engagement with written deliverables. Ask any quote to separate the platform build, application migration, authenticator procurement, evidence collection and independent testing, so you can see which parts recur and which parts a later change in scope would affect. The effort estimates published for the NIST SP 800-171 requirements as a whole are not specific to this requirement, so confirm the effort for 03.05.04 against your own application inventory.

Where organizations usually fall short on replay resistance

Replay resistance usually fails at the edges rather than in the main login flow: a fallback path, an old protocol, an exception nobody wrote down or an account nobody reviews. Each card below names one gap, why it undermines 03.05.04, and the check that closes it.

Password-only fallback on privileged accounts

Administrators often keep a password-only path for break-glass access, recovery or helpdesk resets. A static password can be captured and reused, so the replay-resistant mechanism protects only the accounts that never need it. Check every privileged sign-in route, including console, SSH, VPN and directory admin consoles, and confirm each one requires a phishing-resistant or nonce-based factor. Close it by enforcing the same mechanism on every privileged path and documenting any break-glass account with its own compensating controls.

Legacy protocols left enabled

Older authentication methods can remain available beside a modern identity provider, letting a user or attacker bypass the challenge-based flow entirely. Directory services, mail clients and remote access gateways are common places where basic or static-credential protocols survive a migration. Inventory every protocol each system accepts, not just the one the identity team configured, and confirm that legacy options are disabled or restricted. Close it by removing legacy protocol endpoints from production and recording the one-time check in the configuration baseline.

OTP codes without a replay design assumption

Time-based or one-time codes resist replay only when the verifier rejects a code it has already accepted and limits the time window in which it is valid. Many teams enable an authenticator app and assume the factor is replay-resistant without checking how the server handles reuse. Confirm that the verifier stores recently accepted codes, bounds the window and rejects reuse within it, and that SMS or email codes are not treated as equivalent. Close it by testing a captured code against the live login flow and keeping the result as evidence.

Undocumented exceptions

Exceptions to the authentication standard often appear as a one-off application setting, a vendor request or a temporary firewall rule that never gets recorded. An assessor who asks why a system authenticates differently has no decision record to examine, and the system security plan no longer describes what runs. Keep a register of every exception with its owner, the systems affected, the compensating control and an expiry date. Close it by reconciling the register against actual configuration at each review cycle.

Service accounts excluded from review

Service accounts, API identities and automation users are often excluded from identity reviews because they do not have a person behind them. Their credentials can be long-lived static secrets that are transmitted repeatedly, which is the pattern that replay attacks exploit. Include every non-human identity in the authentication inventory, record how each one authenticates, and check whether it uses a mechanism that resists replay or a secret that could be intercepted. Close it by assigning each service identity an owner and a rotation or certificate-based design.

No test evidence

Configuration screenshots show intent but not behavior, and assessors using the test method look for proof that replay resistance works in the deployed system. Many organizations cannot show a recorded attempt to reuse an authentication message being refused. Build a repeatable test that captures a valid authentication exchange, replays it and confirms rejection, then retain the results with the date, system version and tester. Close it by scheduling the test after each change to the identity provider or its protocol configuration.

Questions buyers ask about 03.05.04 cost, effort and outsourcing

What does 03.05.04 ask the internal team to do?

Your internal team has to decide which accounts and access paths need replay-resistant authentication, configure identity mechanisms that use nonces or challenges, and keep the evidence that shows it works. The requirement covers access to both privileged and non-privileged accounts, so the work starts with an inventory of every login path, including administrator consoles, remote access and service sign-ins that rely on recorded messages. Staff with system operations and account management responsibilities will be interviewed by an assessor, so they need to explain how the mechanisms are configured and how they are monitored. Expect the internal team to own the policy, the configuration decisions and the change records. Replay resistance is a narrow requirement with two determination statements in SP 800-171A Rev. 3, so the internal effort is mostly scoping, configuration review and evidence gathering rather than new policy writing. Confirm with your assessor which artifacts they will request before work begins.

Can we implement 03.05.04 ourselves without outside help?

Yes, many organizations with an existing identity team can do the work alone, provided they have people who understand the protocols and can test them. The main gap is usually not the configuration itself but proving it. Assessors examine documentation, interview staff and test the mechanisms, so the organization needs a clear record of which authentication flows use nonce or challenge-based protocols and how that was verified. Outside help is most useful when the environment is heterogeneous, when identity federation spans several applications, or when the internal team has not tested replay resistance before. An implementation partner can prepare systems and evidence, but only an independent assessor issues a determination. Ask any partner to state in writing which tasks it performs, which remain with your staff and what artifacts it will hand over.

How long does 03.05.04 take to implement?

The duration depends on how many authentication paths you have and how much of the identity stack already uses challenge-based protocols. No researched duration is available for this requirement, so the figure to confirm is your own environment. A narrow scope, such as one administrative portal that already uses a time-synchronous one-time authenticator, takes far less time than a company-wide estate with legacy applications that send reusable credentials. Work in the order of inventory, configuration, testing and evidence collection, and build in time for the assessor's interviews and any remediation they raise. Ask a potential partner for a timeline that depends on a written scope, and ask how it accounts for legacy systems that cannot be changed quickly.

What drives the cost of meeting 03.05.04?

Cost is driven by the number of authentication paths, the age of the identity stack, and how much testing and documentation the assessment requires. The main cost components are internal staff time, any licensing for identity platforms, the work of an implementation partner if you use one, and the fees of an independent assessor. Some costs are one-time, such as configuration, testing and initial documentation. Others recur, such as reviewing the mechanisms after changes, maintaining evidence and preparing for reassessment. Costs rise when legacy applications need replacement or wrapping behind a modern identity provider, and fall when most sign-ins already go through a central identity service. Ask any quote to separate one-time implementation, recurring support and assessment fees, and to name which licensing costs are included. No price is given here because no researched figure supports one.

What does a partner deliver for 03.05.04 and what does the auditor do?

A partner prepares the systems and evidence, while the organization owns its controls and an independent assessor or certification body issues any determination. For 03.05.04, a partner can scope the authentication paths, configure supported identity platforms, test replay resistance, and assemble the configuration records, design documentation and audit logs that an assessor will examine. The assessor then examines those artifacts, interviews personnel and tests the mechanisms against the two determination statements. A partner does not certify compliance or write the assessment result. Keep the roles separate in the statement of work so that your team understands who signs off on each deliverable and who answers assessor questions.

Does 03.05.04 change if we choose Rev. 2 or Rev. 3?

The substance of 03.05.04 is the same in both revisions, but the assessment you face depends on which revision your contract requires. NIST's change analysis traces 03.05.04 to Rev. 2 requirement 3.5.4 and classifies the change as editorial only. CMMC Level 2 still uses the Rev. 2 requirements, and it assesses 3.5.4 as IA.L2-3.5.4, worth 1 point under the 32 CFR 170.24 scoring methodology. Recent DoD guidance names Rev. 2 explicitly while CMMC Phase 2 is suspended, and a proposed FAR overhaul would move civilian contracts toward Rev. 3. Because the replay-resistance work is largely the same under both, most organizations can prepare once and map the evidence to whichever revision applies. Confirm the revision named in your contract and any applicable deviations before scoping the work.

How DeployOpen scopes and prepares replay-resistance evidence

DeployOpen works on a fixed scope agreed in writing before work starts. The cards below follow the path from choosing the identity platform to handing the organization configuration and test evidence that an independent assessor can examine, interview against and test. DeployOpen prepares that material. It does not issue assessment reports or certifications; independent assessors and DoD assessment bodies do.

Scoping the authentication boundary

Before any build, we agree which systems fall under 03.05.04 for privileged and non-privileged accounts, including web applications, VPN and remote access, administrative consoles and cloud management planes. Each in-scope path is listed with its sign-in method and the component that performs the challenge. Ask for this inventory in the written scope, because an assessor will start from it and any path left out becomes an open question during the examination.

Deploying the identity platform in your environment

We plan and install the self-hosted identity provider inside your cloud accounts, data center or air-gapped network, so authentication messages never leave your boundary. Applications are connected to the provider so that sign-in is delegated rather than handled by each application separately. The deployment record should name the hosts, versions, database and high-availability design, which is the baseline an assessor will compare the running system against.

Configuring challenge-based second factors

We configure MFA methods that rely on nonces or challenges, such as passkeys, WebAuthn security keys and time-based one-time codes, and disable weaker methods that a recorded message could replay. Each platform handles this differently, so the exact policy settings are confirmed per product during planning. Keep the policy export and a list of disabled methods, because these settings are the core of the replay-resistance claim.

Producing configuration and audit records

We export the authentication settings, enabled factor types, session and token lifetimes and the logs that show challenges being issued and accepted. These artifacts answer the examine method directly, since assessors review configuration settings and system audit records rather than relying on a description of intent. Agree with us which logs are retained, where they are stored and who can read them, because the evidence must remain available for the assessment period.

Running replay and bypass tests

Our security testers attempt to capture and reuse a prior authentication exchange, submit an old one-time code and downgrade a session to a weaker method. The results are recorded with the request, the expected outcome and the observed outcome, so the test method has a reproducible record. Findings go back into configuration before the evidence pack is closed. The test scope and rules of engagement are agreed in writing before testing begins.

Handing over evidence and ownership

The final package contains the scope inventory, deployment record, configuration exports, test results and a mapping of each artifact to the two determination statements for 03.05.04. Your organization owns the controls and the operating procedures, and the assessor decides whether the evidence is sufficient. Confirm with your assessor which format they accept and whether they want interview access to the administrators who run the platform.