What 03.01.11 session termination asks you to prove
A contract or assessment that requires NIST SP 800-171 will test 03.01.11 Session termination, and the first thing an assessor looks for is a defined, automated end to a user's logical session. The requirement asks your organization to terminate a user session automatically after conditions or trigger events that you define. Its only organization-defined parameter (ODP) is the list of those conditions or trigger events that require a session disconnect. NIST does not supply that list for you. If a federal agency does not specify values, your organization must assign them, and an assessor will check both that the ODP is defined and that the system actually acts on it. Inactivity periods, time-of-day restrictions and certain incident responses are the kinds of triggers NIST uses as examples in its discussion, so your list should name the specific triggers that apply to your environment.
The requirement is easy to confuse with two neighbors. 03.13.09 Network disconnect ends the network connection, while 03.01.11 ends the user's logical session, so a session can close while the connection stays up, or the reverse. 03.01.10 Device lock keeps the device locked and requires re-authentication to resume, but the session itself may remain open behind the lock. Document these three controls separately in your system security plan so the assessor can see which mechanism satisfies which requirement.
Two issues tend to make this requirement hard. The first is an undefined ODP: teams implement a timeout, then cannot show a written list of the conditions that drive it, which leaves the assessment incomplete. The second is server-side applications whose sessions never end, because the session lives in a web tier, a database connection pool or a single sign-on token that outlives the browser. Before you start, inventory the applications that hold CUI, confirm with each owner where session state lives, and test whether a logout or timeout actually invalidates it. Your assessor will likely interview system administrators and developers about exactly this, so the answers must match the configuration.
Which systems and sessions fall under session termination
Session termination under 03.01.11 applies to every logical session that reaches CUI or security functions, so the scope is set by where those sessions start and end. Each scoping choice below adds or removes a session type that the organization must configure, define trigger events for, and evidence.
CUI-handling systems
Any system that stores, processes or transmits CUI needs a defined rule for when a user's logical session ends, such as after inactivity or on a trigger event. Start with the system security plan boundary and list each interactive login path, including desktops, thin clients and virtual desktops. Confirm that each path uses the same organization-defined conditions, because an assessor will sample sessions from several of them. Document the settings for each path separately.
Web applications
Browser-based applications often keep their own session timers separate from the operating system. A user may stay signed in to the application after the workstation has locked, or the reverse. Check whether the application invalidates its session token after the defined condition and whether it does so on the server side, not only in the browser script. Record the timeout value and the trigger events in the same list you use for other session types.
Privileged administrator sessions
Administrative sessions into servers, directories and security tools usually carry the highest risk and often run on separate access paths. Decide whether privileged sessions use shorter conditions than standard user sessions, and document that choice as an organization-defined parameter. Include console, SSH and remote management sessions. Confirm that a session opened with an administrator account ends under the same rule, and that the termination is logged for review.
Remote and VPN users
A VPN or remote access gateway can end the network connection while the user's application session stays open on the endpoint. That is the difference between network disconnect under 03.13.09 and session termination under 03.01.11. Check both layers: the tunnel timeout and the logical session timeout inside the application or operating system. Test a remote session from a home network and from a managed device, since the settings often differ between them.
Third-party SaaS with configurable sessions
A SaaS platform that processes CUI is part of the system if the organization controls its session settings. Confirm whether the administrator console exposes an idle timeout, absolute session lifetime or forced sign-out, and whether the settings apply to all users or only to new sessions. Where the provider sets the value and the organization cannot change it, record that as a limit and ask how the provider documents the behavior. Export the configuration as evidence.
Identity provider and single sign-on sessions
Centralized sign-on adds a session at the identity layer that can outlive the sessions of the applications it serves. Map which applications accept sessions from which identity provider, and decide whether ending the application session also ends the identity session. Open-source options such as authentik, which supports OAuth2, OpenID Connect, SAML, LDAP and proxy providers, and FreeIPA, which provides single sign-on for Linux and UNIX through a Kerberos KDC, each need this mapping written down. Confirm the behavior in your own test environment before relying on it.
How an assessor tests session termination
This table maps each SP 800-171A Rev. 3 assessment method for 03.01.11 to the objects an assessor examines, interviews or tests, and the evidence to prepare. Read it as a checklist of what must exist, match and actually work, since a defined parameter with no configuration behind it will fail the review.
| Assessment step | What the assessor checks | Evidence to prepare | Where it usually fails |
|---|---|---|---|
| Examine: policy and procedures | Access control policy and session termination procedures exist and state the conditions or trigger events that end a logical session | Access control policy, session termination procedure, named owner and review date | Policy says sessions end after inactivity but names no specific value or trigger |
| Examine: ODP list | The organization has defined the conditions or trigger events that require session disconnect, as the 03.01.11 parameter asks | Written list of trigger conditions with the value or event for each, approved by the owner of the system | List is missing, generic, or stored only in a team member's notes |
| Examine: system design and configuration | System design documentation and configuration settings implement the listed triggers for the in-scope systems | Design documents, configuration exports or screenshots showing timeout, inactivity or event settings per system | Settings exist on some systems or applications but not on the database, admin console or remote access tools |
| Interview: security personnel and administrators | Staff with security responsibilities explain how triggers are set, changed and monitored, and why each trigger was chosen | Interview notes or a short written walkthrough from the administrators who manage session settings | Administrators describe the intended behavior, but cannot show where the setting is applied |
| Interview: system developers | Developers confirm how application sessions end, including logout on inactivity and handling of expired tokens | Developer statements tied to the application's session code, identity provider settings and documented behavior | Developers assume the identity provider handles timeouts, while the application keeps its own session open |
| Test: automated termination mechanism | The mechanism actually ends a logical session when a listed trigger occurs, in a controlled test | Test plan, test record with timestamps, before and after session state, and the trigger that was used | Test only confirms that the network connection drops, which is the separate requirement 03.13.09 |
| Determination: ODP is defined | A second determination statement checks that the parameter value is defined, so an undefined trigger fails even if a timeout exists | Signed ODP definition with a version date that matches the system security plan | Timeout is set in the system, but no one has recorded it as the organization-defined value |
| Illustrative finding | A trigger of 30 minutes of inactivity is listed in the policy, but the application's session setting is three hours | Configuration export that contradicts the policy, plus a corrected setting and retest record | Mismatch between the written value and the live setting is a common reason for a finding |
Sequence for implementing session termination
The sequence turns 03.01.11 from a policy statement into a configured, tested control with evidence at every stage. Each step closes with an artifact an assessor can examine, interview against or test.
Define trigger conditions and ODP values in policy
Start by deciding which conditions end a user's logical session on each CUI system. Rev. 3 leaves the value of the 03.01.11 organization-defined parameter to the organization unless the federal agency specifies it, so the organization must set it. NIST's examples of trigger events include inactivity periods, time-of-day restrictions and responses to certain incidents. Record the chosen conditions and values in the access control policy and the session termination procedure, and have the system owner and security lead approve them. The step is done when the list of conditions or trigger events requiring session disconnect exists as a dated, approved document that matches the policy. Confirm the exact ODP wording against your contract or agreement before you approve it.
Inventory session types across CUI systems
Identify every system in the CUI boundary that creates a logical session, including operating system logons, web applications, administrative consoles, databases, virtual desktops, and remote or mobile access paths. Note the session owner, the authentication source and whether the session is interactive or service-based. Separate user sessions from network connections, because 03.01.11 covers ending the user's logical session while 03.13.09 covers the network connection. The inventory is complete when each CUI system lists its session types, the component responsible for each, and the trigger conditions that apply to it. Store the inventory with the system security plan or its supporting documentation so an assessor can compare it against the configuration.
Configure automated termination per application or platform
Enable session termination in each component the inventory identified, using the settings each platform provides for inactivity timeouts, maximum session length, or event-driven logout. Where a platform cannot end a session automatically, document the gap and the compensating approach in the plan of action, and do not treat a manual process as an automated mechanism. Centralized identity providers can help consistency when applications delegate sign-in to them, but confirm that the provider's session lifetime and the application's session lifetime are both set to the approved values. Export the configuration files or screenshots of settings as evidence. The step is done when every inventoried session type has a configured trigger that matches the approved list.
Test each trigger against the approved conditions
Test every trigger condition on every session type in a non-production or controlled environment before relying on it. For each trigger, run a session, meet the condition (for example, let inactivity pass the approved threshold, or attempt a session outside an allowed time window), and confirm that the logical session ends and the user must authenticate again. Record the test date, the tester, the expected result, the actual result and any failure. Confirm that the network connection behavior is evaluated separately under 03.13.09. Retest after any configuration change. The step is done when each trigger has a passing test record, and failures have tickets with an owner and a retest result.
Record outputs at each step for assessment
Assemble the artifacts produced in the earlier steps into one evidence package for 03.01.11: the approved policy and procedure, the trigger list with ODP values, the session inventory, configuration exports, test records and any exceptions with their compensating controls. Map each artifact to the examine, interview and test objects that SP 800-171A Rev. 3 lists for this requirement, so an assessor can find them quickly. Interview the administrators and developers who configured the controls and confirm that their description matches the documents. Keep the package under version control and re-review it when the system, the contract or the ODP values change. The step is done when an assessor can trace each documented trigger to a configuration setting and a passing test.
Why logical session termination is not network disconnect or device lock
03.01.11 ends the user's logical session, and that is a different act from ending the network connection or locking the screen. When the requirement is met, the session a user established with the system (an application login, a remote desktop session, a web session token) is terminated after an organization-defined condition or trigger event occurs. The network path may stay up, and the device may still be running. NIST's discussion of 03.01.11 points to 03.13.09 (Network disconnect) precisely because the two requirements address different objects. A firewall or VPN rule that drops a TCP connection after idle time may satisfy 03.13.09 while leaving an authenticated application session alive on the server, which fails 03.01.11.
NIST's examples of trigger events show why the distinction matters in practice. Inactivity periods are the most familiar, but NIST also names time-of-day restrictions and responses to certain incidents, such as a session that an alert has flagged as suspicious. Each of these needs the system to end the session on the server or identity side, so that a later request with the old session token is refused. Device lock under 03.01.10 is different again: it keeps the session and the device logged in but hides the content and requires the user to re-authenticate. A screen lock therefore does not terminate anything, and an assessor will not accept it as evidence for 03.01.11.
Before relying on a configuration, confirm which layer enforces each behavior. Ask the team to list the trigger events the organization has defined as the value of the organization-defined parameter for 03.01.11, then trace each one to a mechanism, such as session timeout settings in the application, token lifetime and revocation in the identity provider, or a session-end action on the endpoint. Test each trigger by hand and confirm that the old session is refused, not just that the network socket closed. For a fuller view of how an assessor reads the examine, interview and test methods, see the NIST SP 800-171A Rev. 3 assessment procedure for 03.01.11.
Evidence that passes a session termination test
An assessor testing 03.01.11 looks for four things: a documented rule, a defined list of trigger conditions, a design that explains how sessions end, and proof that the configured behavior actually works. The cards below cover each artifact and how to keep it current between assessments, so the evidence matches the system on the day it is reviewed.
Session termination procedure
This is the written procedure that tells administrators how session termination is configured, who owns it, and how exceptions are approved. SP 800-171A lists the procedure among the examine objects, so the assessor will compare it with what the system actually does. Check that it names the systems in scope, the ODP values in use, and the steps for changing them. Tie the document to the access control policy so the two do not contradict each other.
Defined trigger conditions list
03.01.11 requires the organization to define the conditions or trigger events that end a session, and assessors check that this list exists and is populated. The list should cover inactivity periods, time-of-day restrictions and incident-driven responses, which are the examples NIST gives. Record the value chosen for each condition and the reason for it. An undefined list fails the ODP check even when the system terminates sessions correctly.
System design documentation
Design documentation shows where session state lives, which components enforce termination, and how the identity provider, application servers and endpoints interact. Assessors use it to confirm that the termination mechanism covers every path a user can reach the system through. Keep diagrams and component lists in the system security plan so they are updated when an application is added. Note explicitly where session termination is delegated to a platform and where it is handled by the application itself.
Configuration exports with timeout settings
Configuration exports are the proof that the defined conditions are set in the running system. Capture the timeout values, idle limits and trigger rules from each identity provider, application and endpoint policy, then store them with the date and the system name. For open-source platforms, export the relevant settings from authentik providers or FreeIPA policy, and check that they match the procedure. Scheduled snapshots, such as a weekly export compared against a baseline, reveal drift before an assessor does.
Test records showing sessions ending
Test records show that the mechanism works, which the test method in SP 800-171A requires. Record a test for each trigger condition: start a session, meet the condition, and capture the log entry or screen showing the session closed and re-authentication required. Keep the test scripts, the tester, the date and the result. Retest after every change to a trigger value or a platform upgrade, because a configuration can look correct on paper and still fail in practice.
Change tickets for session settings
Change tickets link each timeout or trigger change to an approver, a reason and a rollback plan. Assessors ask for them when a configuration export shows a value that differs from the previous assessment. Require a ticket for any change to session length, inactivity thresholds or incident responses, and attach the configuration diff. This is also how you show that the ODP values were set deliberately rather than left at defaults.
What meeting 03.01.11 costs in money and effort
This table breaks down the cost components of meeting 03.01.11 Session termination, who is paid for each one, and whether it is one-time or recurring. Use it to build a quote request and to see which items your own environment will drive up or down. No figures are supplied for this requirement, so confirm amounts and durations with each provider and assessor in writing.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Defining session termination triggers | Internal security and compliance staff, with optional outside help | One-time, revisited on policy change | Number of trigger types such as inactivity, time-of-day and incident responses |
| Configuring applications and identity provider settings | Internal platform engineers or an implementation partner | One-time per application, plus changes | Number of applications and whether sign-in is delegated to a single identity provider |
| Session termination tooling or licenses | Vendor or open-source project, with support contract if purchased | Recurring if licensed or supported, otherwise low | Choice of self-hosted open-source components versus commercial products |
| Evidence collection and upkeep | Internal compliance or security operations staff | Recurring, tied to review cycles and system changes | Frequency of configuration changes and how automatically settings are exported |
| External testing or review of session behavior | Security testing provider or internal assessor | Typically one-time before assessment, periodic afterward | Number of systems in scope and whether testing is combined with other requirements |
| Assessor time | Independent assessor or certification body, as the organization's contracting authority requires | One-time per assessment cycle | Number of interviews, examine objects and test objects the assessor must cover |
| Ongoing ODP maintenance | Internal governance owner | Recurring, at each review of the system security plan | Number of documented trigger conditions and how often they change |
Open-source tools that produce session termination evidence
authentik (MIT) is an identity provider that applications delegate sign-in to through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Because sign-in for many applications passes through one place, it can produce evidence of how sessions are issued and ended at the application edge. It only governs applications that actually delegate to it, so applications with local accounts need separate evidence.
- Provider session settings: the session and token lifetime settings on each provider, which an assessor can compare against the conditions your organization defined for 03.01.11.
- Application integration: a list of which CUI applications use an authentik provider, since any application outside that list falls outside this evidence.
- Logout behavior: whether logout and single logout end the session at both the application and the identity provider.
- Event records: the authentication and session events your deployment keeps, showing when sessions were issued and when they ended.
Confirm which session lifetimes, inactivity limits and logout paths apply to each provider and application you run, and test each one against the trigger events you defined. The authentik provider documentation lists the provider types your version supports.
FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Kerberos tickets are time-limited credentials, so ticket lifetime and renewal policy determine how long a user's identity stays valid on joined hosts. That bears on 03.01.11, but FreeIPA governs identity and tickets, not every shell, desktop or SSH session on each host, so session end still depends on host-side settings.
- Ticket lifetime policy: the maximum ticket lifetime and renewal window configured for the realm and for individual services, which bound how long a credential stays valid.
- Host enrollment: the list of joined hosts, showing which Linux and UNIX systems the policy covers.
- Access rules: host-based access rules showing which accounts may log in to which hosts.
- Host-side timeouts: the shell, display manager and SSH idle settings on each host, which FreeIPA does not set by itself and which need separate evidence.
Confirm which hosts honor the ticket policy, whether ticket expiry ends an interactive session or only blocks new authentication, and how that behavior is tested on each distribution you run. The FreeIPA project overview describes the components involved.
Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most policies ship based on CIS benchmarks, and you can extend them with custom policies that check files, directories, registry keys and running processes, and that recommend remediation. Wazuh does not end sessions. It shows whether the settings that should end sessions are present on each endpoint, which is evidence of configuration, not proof of runtime behavior.
- Custom session policy: a YAML policy that checks the session-related settings your defined conditions depend on, such as an SSH server idle timeout, with values that match your own ODP assignments.
- Per-endpoint results: scan results showing which endpoints passed each check and the remediation Wazuh recommends for those that failed.
- Process checks: checks against running processes, useful for confirming that a required session service is active.
- Scheduled scans: repeated scans on a schedule you set, showing whether the setting held over time and not only on the day of the assessment.
Confirm that your custom policy values match the conditions you defined, that each check reads the file actually in effect on each platform, and that a passing scan is paired with a test showing the session really ends. The Wazuh Security Configuration Assessment documentation explains how policies are written and run.
Fleet (MIT) policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each policy. For 03.01.11, this suits checks on endpoint state that supports session termination, such as whether a session timeout or screen lock setting is enforced on a device. The per-device result gives an assessor a population they can sample from, and it shows coverage by device group.
- Query design: each policy written as a yes or no osquery question, such as whether a session timeout setting is present on a given operating system.
- Fleet grouping: policy results organized by fleet, so you can show coverage for each device set that handles CUI.
- Passing and failing views: the policies page listing which devices pass or fail each policy, suitable for sampling.
- Remediation tracking: failing devices as the working list for fixes, with exceptions recorded where a setting cannot be applied.
Confirm which queries your Fleet version runs, that the osquery tables you rely on report the setting correctly on each operating system you manage, and that a passing policy is backed by a test showing the session actually ends. The Fleet guide to policies describes how policies are built and reviewed.
Common gaps that fail 03.01.11
Session termination assessments tend to fail on the same few points: parameters nobody set, timeouts enforced in one place but not others, and evidence that describes a configuration from a single date. Each card below names one gap and the check that closes it before an assessor finds it.
ODP values never assigned
03.01.11 has one organization-defined parameter: the conditions or trigger events that require session disconnect. NIST does not assign that value, so if the federal agency that holds your contract does not specify it, your organization must. Teams often implement a timeout and never write down which conditions it answers to. The assessor's determination statement that checks the ODP is defined will then fail even when the mechanism works. Action: write the trigger list, get it approved by the system owner, and cite it in the system security plan.
Timeouts only at the VPN
A common setup ends the remote tunnel after inactivity but leaves browser-based and desktop applications signed in with long-lived sessions. The user's logical session in the application continues even though the network path has closed. Because 03.01.11 concerns the logical session, a VPN timeout does not satisfy it on its own. Action: inventory every application that holds a user session for CUI, then confirm each one ends its session on the defined triggers, or that the identity provider revokes the session centrally.
Administrator sessions excluded
Privileged and administrative sessions are often exempted from timeouts so that long-running maintenance is not interrupted. That exemption is the gap an assessor is most likely to test, because administrators hold the broadest access to CUI. If an exemption exists, it needs its own documented justification and its own compensating control. Action: list every administrative interface, including consoles, hypervisors and database tools, and confirm each one follows the same trigger list or has an approved exception on file.
Configurations not tied to triggers
Session settings can exist in a configuration file with no link to the written conditions they are meant to enforce. When the policy says inactivity, but the system is set to a time-of-day restriction or has no incident response trigger, the two documents disagree. NIST's discussion gives inactivity periods, time-of-day restrictions and certain incident responses as example triggers. Action: map each trigger in your list to the exact setting, file or identity provider policy that enforces it, and retain that mapping with the configuration baseline.
Evidence captured once
Teams often take one screenshot or export of session settings during preparation and reuse it for every assessment cycle. Configurations drift after patches, identity provider changes and new applications, so the single capture stops describing the system. An examiner asking for the current configuration and a test of termination will see the mismatch. Action: schedule a repeatable export of session settings and a periodic test that forces a session to end on each trigger, then keep dated results alongside the policy.
Session termination questions buyers ask before hiring help
What does session termination work cost and what drives the price?
Cost depends on how many systems carry logical sessions, how many trigger conditions the organization defines, and how much of the configuration already exists. The organization pays for its own internal time to define the conditions and approve them, and an implementation partner, if used, is paid against a written scope. Most of the cost is one-time setup: writing the session termination procedure, configuring timeouts or identity provider settings, and collecting evidence. Recurring cost comes from reviewing settings after upgrades and keeping evidence current for each assessment cycle. No figure is given here. Ask any provider for a quote that lists each system, each trigger condition, and each evidence artifact to be produced.
How long does session termination take to implement?
Duration depends on scope rather than on the requirement itself. A single application with one defined inactivity period is a small task. A environment with many applications, a mix of identity providers and interactive administrator sessions takes longer because each system needs its own configuration and test. Time also depends on how quickly the organization decides its trigger conditions, since the requirement cannot be met until those are defined. Ask for a timeline tied to a written scope, with milestones for policy, configuration, testing and evidence collection.
Can an in-house team implement session termination without outside help?
Yes, if the team has engineers who can configure session timeouts in each application, identity provider and operating system, and staff who can write the procedure and collect evidence. Many organizations do this internally. The usual gaps are inventory, where teams miss legacy applications or administrator tools, and testing, where a timeout is set but never verified against each trigger condition. An outside partner can help close those gaps, but the organization still owns the control and its decisions.
What does the client need to provide for session termination work?
The client needs to supply a list of systems that hold or process CUI and create logical sessions, access to configuration for each one, and named owners who can approve the trigger conditions. The organization must also decide which conditions apply, such as inactivity periods, time-of-day restrictions or responses to certain incidents, and write them down as the ODP values. Without those decisions, no configuration can be verified. Expect to provide test accounts and a window to run session termination tests without disrupting production users.
Can a consultant or implementation partner issue the session termination assessment result?
No. An implementation partner prepares systems, configuration and evidence, but it cannot issue an assessment result, a SPRS score or a certification. Under NIST's approach, the organization owns its controls and its compliance status, and the federal agency that holds the contract is responsible for how SP 800-171 is applied. Assessments are carried out by the government body or the assessor named in the contract, such as DCMA DIBCAC for certain assessments. Ask any provider to confirm this in writing before work begins.
How does the 1-point CMMC mapping for 3.1.11 affect scoring?
Under CMMC Level 2, which still uses Rev. 2, the session control requirement appears as AC.L2-3.1.11 and carries 1 point in the 32 CFR 170.24 scoring methodology. A single missing point is small on its own, but a requirement that is not met is still a gap that an assessor will record. The point value matters less than the evidence: an assessor will look for the policy, the configured settings and the test results. Confirm the current scoring treatment in the eCFR text before relying on it, since contract rules are changing.
What is the difference between session termination and network disconnect?
Session termination ends a user's logical session on the system, such as an application login, while network disconnect ends the network connection itself. NIST's Rev. 3 discussion treats these as separate requirements. Teams often configure one and assume the other is covered, so ask a provider to show both in the scope and in the evidence.
How DeployOpen scopes session termination for your platforms
DeployOpen plans session termination as a fixed-scope piece of work across the self-hosted open-source platforms you run in your own cloud accounts, data centers or air-gapped networks. Before any configuration changes, the written scope should list each system that holds or reaches CUI, the session types it serves (interactive console, web application, administrative shell, API token sessions), and the trigger conditions your organization has chosen. Because 03.01.11 has one organization-defined parameter, the list of conditions or trigger events that require session disconnect is yours to set, and the scope should record who approved it and where it is documented.
Once the conditions are agreed, the implementation work covers the settings that enforce them on each platform, such as idle timeouts and absolute session lifetimes in identity and application layers, and the logging needed to show that a termination occurred. Identity components like authentik can centralize sign-in for applications that support OAuth2, OpenID Connect or SAML, so session lifetime is set once rather than per application. Fleet policies and Wazuh configuration assessment checks can then confirm that endpoint settings match the approved baseline. The scope should also name which systems are out of reach of these settings and how those gaps will be handled.
DeployOpen prepares the configuration, hardening notes and evidence packages that an assessor will examine and test, including the documented procedure and the configuration records. DeployOpen does not issue assessment reports, scores or certifications. Your organization owns its controls and its SPRS submission, and the assessment itself is performed by the body your contracting agency or the applicable program designates. Ask your assessor early which evidence format they expect, and confirm the applicable Rev. 2 or Rev. 3 requirement set with your contracting officer before the scope is signed.
