SC.L2-3.13.9 Connections termination: evidence and audit

What SC.L2-3.13.9 connections termination requires for CMMC Level 2

SC.L2-3.13.9 requires a contractor's CUI system to terminate network connections associated with a communications session when the session ends, or after a defined period of inactivity, so that an open session cannot be taken over by someone else. It is a 1-point requirement, and it is easy to overlook because it sits beside much larger boundary and encryption requirements. Assessors still test it in full, and a single unmet objective leaves the requirement NOT MET. The requirement comes from NIST SP 800-171 Rev. 2, and the Level 2 assessment is performed against the assessment objectives in NIST SP 800-171A (June 2018), which break 3.13.9 into three objectives: define an inactivity period, terminate network connections at the end of sessions, and terminate them after that inactivity period has passed.

The first objective is the one most often missed. An inactivity period has to be a documented, configured value that the organization chose, not a vendor default that nobody reviewed. Confirm the value in each system component that holds a CUI session, including the VPN concentrator, remote administration tools, web applications that handle CUI, and database or file transfer services. Check the actual setting in the configuration file, the policy object or the device profile, and keep the approval record that explains why that value was chosen. The CMMC Assessment Guide Level 2 expects the value to balance user work patterns against security, so the record should show that the team considered both. For the other two objectives, assessors look for the disconnect mechanism working in practice, which they may test directly, and for configuration settings and audit records that show sessions ending as designed.

If the requirement is not fully met at assessment time, the POA&M rules matter. Under 32 CFR 170.24, SC.L2-3.13.9 is worth 1 point, and because it is not on the exclusion list in 32 CFR 170.21, it may go on a POA&M for Conditional Level 2 status if the score is at least 88 of 110, with closeout due within 180 days. Treat that as a fallback, not a plan. Ask the system owner to confirm the inactivity period, the component list and the evidence location before the assessment begins, and confirm current POA&M and status rules with the DoW CIO and the eCFR text at 32 CFR Part 170, since CMMC implementation timing has changed.

Which systems, sessions and teams fall under the inactivity rule

SC.L2-3.13.9 applies to every network connection that carries a communications session tied to the system holding CUI, so scope starts with the session paths and not only the servers. The cards below cover the components most often in scope and the ownership questions that change how much configuration work falls on the contractor.

CUI workstations and endpoints

Any workstation that opens a session to a system holding CUI is part of the scope, including desktops, laptops and engineering terminals used for remote desktop or secure shell. The timeout can be enforced on the endpoint (screen lock or session logout) and on the server side (idle session termination), and assessors will want to see which layer you rely on. Confirm that the setting is applied through managed configuration and not left to each user.

Servers and application sessions

Interactive sessions on servers, database consoles and internal applications are where a hijacked session does the most damage. Check each platform for its own idle timeout, since operating system, application and database settings often sit in different places. Record the configured value for each system so the defined inactivity period can be shown per system during assessment.

VPN and remote access gateways

VPN and remote access gateways are a high-risk boundary because they hold the network session between a remote device and the internal network. Confirm both the gateway's idle timeout and its maximum session lifetime, and check whether a dropped tunnel terminates the connection on both ends. Ask your VPN vendor or integrator to document where each timer is set and what happens to traffic when it expires.

Administrative consoles

Administrative interfaces for firewalls, hypervisors, identity systems and security tools carry the most privileged sessions in the environment. They are often left with long or no timeouts because administrators find them inconvenient. Treat these consoles as a separate scoping group, set a defined inactivity period that matches their risk, and keep evidence of the setting with the change record that approved it.

Cloud and SaaS sessions

For SaaS and cloud services that carry CUI, the first scoping question is whether session settings are inherited from the provider or must be configured by the contractor. Some providers publish fixed idle timeouts that you cannot change, while others expose tenant-level policies that you must set. Request the provider's documentation and any compliance package that describes session behavior, then record which settings are provider-controlled and which are yours.

Shared and service accounts

Shared and service accounts create sessions that no single person owns, so an inactivity rule can be missed when nobody is responsible for it. Decide whether a service session should time out at all, since a forced disconnect can break a scheduled job, and document the answer. Where a shared login is used for interactive access, the timeout still applies, and the owning team must be named in the system security plan.

How an assessor tests session termination under 3.13.9

This table maps the three SP 800-171A assessment objectives for SC.L2-3.13.9 to the test an assessor runs, the evidence they request and the findings that usually cause a gap. Read each row as one objective, and remember that the requirement is MET only when every applicable objective passes with final evidence.

Objective	How the assessor tests it	Evidence requested	Common findings
Define the inactivity period	Confirms the organization has set a specific, documented inactivity period for the network connections in scope and that it applies to the systems handling CUI	Approved configuration standard or system security plan entry stating the period, plus the configuration setting that enforces it	Period is stated in policy but never configured, or the value differs between the policy, the VPN, the application and the operating system
Terminate connections at the end of sessions	Starts a session, ends it normally and checks whether the network connection closes rather than remaining open	Test record showing session close and connection teardown, plus audit records of session end events	Application logs the user out but the underlying network connection or tunnel stays up, or sessions survive a browser close
Terminate connections after the inactivity period	Leaves a session idle for the defined period and checks that the connection is dropped without user action	Timed test result, idle timeout settings on the boundary device, VPN gateway or application, and audit records of forced disconnects	Timeout is set on the application but not on the VPN or remote access gateway, or idle sessions remain active after the stated period
Mechanism review	Assessor may test the mechanism that implements network disconnect directly, not only the documentation	Screenshots or exports of the live configuration, and a demonstration on a representative system	Configuration exists in a template but is overridden on production systems, or a vendor default was never reviewed
Audit records	Reviews whether disconnect events are recorded so the organization can show the control operated	Log entries showing session termination and idle disconnect events, with timestamps and user or session identifiers	Disconnects are not logged, logs are not retained, or events cannot be tied to a session
Final evidence	Accepts only evidence in final form, not drafts, and checks each objective separately	Approved, dated configuration baselines and test results that match the system as it runs today	Draft policy or outdated screenshots presented for an objective, which leaves the requirement not MET

Implementing session termination step by step

This sequence turns the SC.L2-3.13.9 requirement into a documented, tested and repeatable configuration, so an assessor can see where connections end, why the inactivity period was chosen, and that the disconnect happens in practice.

Inventory every connection type that carries CUI
Start by listing each network connection path that carries CUI or provides access to a system that holds it. Include user sessions to web applications, administrative shells, remote desktop and VPN sessions, API connections, database sessions, and service-to-service links between components. Assign each entry an owner and note the platform that terminates it, such as a firewall, reverse proxy, application server, or operating system. The output is a session inventory tied to the system boundary in your system security plan. The step is complete when someone who is not the author can point to each CUI-bearing session type and name the component responsible for ending it.
Define and justify the inactivity period
Set the inactivity period for each session type or tier, then write down the reasoning. The CMMC Assessment Guide asks organizations to balance user work patterns against security, so record the typical working pattern for each group, the sensitivity of the data reached through the session, and any operational constraints such as long-running batch jobs. Have the system owner and security lead approve the values in a signed inactivity standard. Ask your assessor's expectations early, because SP 800-171A expects you to define the period explicitly. The output is an approved standard with a rationale for each value, and the step is complete when every session type in the inventory maps to a documented period.
Configure session end and idle timeouts
Apply the approved values to each component in the inventory. Use the native settings of each platform, such as idle session timeout in the application framework, session lifetime on the identity provider, SSH client and server keepalive and idle settings, VPN idle disconnect, firewall state timeouts for idle connections, and database idle connection limits. Where a component cannot enforce a timeout itself, document the compensating mechanism and who operates it. Keep changes under configuration management so each setting has a ticket and an approver. The output is a configuration export or screenshot for every component, and the step is complete when no CUI-bearing session type relies on a default value you have not reviewed.
Confirm session termination at the network layer
Some sessions end at the application, while the network connection beneath them may persist. Verify that the boundary devices and hosts also release the underlying connection at session end. A firewall rule set with stateful tracking, such as an OPNsense policy that logs rule matches, can show whether idle flows are removed from the state table. Check the behavior of load balancers and reverse proxies that keep upstream connections open. The output is a short technical note describing which layer ends each connection type, and the step is complete when the note matches the inventory from the first step without gaps.
Test that disconnects actually occur
Configuration alone does not show that the mechanism works. For each session type, run a test where a session is opened, left idle past the defined period, and then checked for termination. Repeat with a test that ends the session by a normal logout or by the defined session lifetime. Record the account used, the start and end times, the component logs, and whether any follow-up request is refused. Include the scenario where a user keeps a session open on a shared workstation. Keep the test scripts or procedures in version control so they can be rerun after upgrades. The output is a dated test record with results per session type, and the step is complete when every test shows termination within the defined period.
Monitor and log termination events
Termination should leave a trace in the logs that the audit and accountability controls collect. Confirm that session timeout, logout, and forced disconnect events are written to a central log store with time stamps, and that the events identify the account and session. Where the platform supports it, forward these events to a SIEM such as Wazuh, and set a review routine that checks for failed terminations. The output is a sample set of exported log events showing each termination type, and the step is complete when an assessor could trace one session from start to forced end using only the stored records.
Record the configuration baseline and review schedule
Finish by capturing the approved state as a configuration baseline. Export the configuration files or policy settings for every component, store them under change control, and reference them in the system security plan. Set a review trigger that runs when the inactivity standard changes, when a platform is upgraded, or when a new connection type is added to the inventory. Assign the review to a named owner. The output is a baseline package containing the standard, the configuration exports, the test record, and the review log. The step is complete when the package is in final form, because SP 800-171A only accepts evidence in final form, not drafts.

How to set the inactivity period without breaking user work

The CMMC Assessment Guide for Level 2 tells organizations to balance user work patterns against security when they choose the inactivity period that forces a network connection to terminate. In practice, the inactivity period is a business decision with a security boundary, and the assessor will expect to see that someone weighed both sides. A value that is too short logs out engineers in the middle of a build and pushes staff toward workarounds such as shared sessions or disabled timeouts, which creates a bigger problem than the one the requirement addresses. A value that is too long leaves a session open for an attacker to take over after a user walks away. Start by listing the applications that hold CUI sessions (remote desktop, VPN, the CUI file share, the ticketing and email clients that reach CUI) and recording how long your users actually sit idle in each one. That baseline is the evidence behind your number.

Different systems usually justify different values, and the assessment is easier when you document that split rather than applying one global setting. Interactive workstations and collaboration tools often get the shortest period that users will tolerate, with the screen lock and session timeout set in the operating system or identity platform. Administrative consoles, firewall management interfaces and hypervisor portals are typically held to a shorter period than user desktops because a hijacked administrative session carries more risk, and the administrators should expect to re-authenticate often. Long-running jobs such as database replication, backups or batch processing are a different case: they are not interactive, so an inactivity timer may not apply to them at all, and the justification should explain how those processes are protected by other controls such as authenticated service accounts and encrypted channels. Record each exception with the system name, the value, the reason and the compensating control, and ask your system security plan owner to confirm that the entries match how the systems are actually configured.

Approval and review close the loop. The decision should be signed off by the system owner, who is accountable for the risk, and the approval should reference the documented baseline and the exception register. Revisit the values when user workflows change, when a new administrative tool is added, or when a security incident suggests sessions are being abused. Confirm with your assessor, before the assessment, how they expect the approval and review records to be presented, because the evidence must be in final form to count. The DoW's assessment guidance is the natural place to check the wording of the objectives you will be measured against, and your own configuration exports should show the timeout values in force on each system.

Evidence that proves connections are terminated

An assessor testing SC.L2-3.13.9 looks for a defined inactivity period, proof that the setting is enforced, and records showing that sessions actually end. Each artifact below covers one part of that chain, and each one goes stale unless someone maintains it when the environment changes.

Documented inactivity standard

This is the written decision that defines the inactivity period and the session end conditions for each system in scope. SP 800-171A requires the organization to define the period before anything else can be tested. Record the value, the systems it applies to, the business reason for the chosen period, and the owner who approved it. The CMMC Assessment Guide asks organizations to balance user work patterns against security, so the document should show that tradeoff was considered rather than copied from a default. Ask the assessor early whether they expect the standard as a stand-alone policy or as a section of an existing access control or system security document.

Timeout configuration exports

Screenshots and exported configuration files show the timeout actually set on each component: the VPN concentrator, remote desktop gateways, web application servers, bastion hosts and admin consoles. Capture the setting with the system name, the date, and the file path or menu location, so the assessor can match it to the documented standard. Exports are stronger than screenshots because they can be diffed between assessments. Where a platform applies timeouts through a central policy, export the policy and the list of systems it is bound to, not only one example device.

Audit records of forced disconnects

Logs showing that the system terminated sessions after the inactivity period prove the mechanism works in production, not only in a configuration file. Pull entries that record session start, last activity, and the disconnect event for a sample of sessions across the review period. Confirm that the log source is protected and time-synchronized, since an assessor will question logs that could have been edited. If a platform does not write a disconnect event, document the alternative evidence and ask the assessor whether it is acceptable before the assessment.

Timed session test results

A test record shows an actual session left idle, the timer expiring, and the connection closing. Run the test on each in-scope system type, record the start time, the idle duration, the disconnect time and the result, and keep the tester's name. Repeat the test after any upgrade or configuration change that touches session handling. A test performed once at implementation does not show that the control still operates at the time of assessment.

Change records for timeout alterations

Every change to an inactivity period needs a ticket that shows who requested it, the reason, the approval, the date applied, and the systems affected. Store the previous and new values so the history is visible. Link each change to the configuration export it produced, and update the system security plan entry and the documented standard in the same change. Assessors often find that the standard says one value while the system runs another, so treat that mismatch as a defect to close, not a finding to explain.

System security plan entry

The system security plan states how SC.L2-3.13.9 is implemented for each in-scope system: the inactivity period, the components that enforce it, and where the evidence is kept. Write the entry so it names the same values as the configuration exports and the standard. Review it at each planned update and after any architecture change that adds a remote access path or a new administrative interface. Confirm with your assessor and your own contracting officer which plan format and review cycle they expect, because requirements for plan maintenance are set by the program and by your contract.

What meeting SC.L2-3.13.9 costs in money and effort

This table breaks the cost of implementing and evidencing connection termination into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No figures are given because none were supplied for this requirement, so use the right-hand column to structure requests for quotes from any provider, including DeployOpen, and to compare them on the same basis.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Configuration engineering per platform	Internal IT or an implementation partner	One-time, with rework after upgrades	Number of platforms, legacy systems that lack native idle timeouts, and differing session handling across vendors
Inactivity period definition and approval	Internal security and business owners	One-time, revisited on policy change	Number of user populations and workflows, since the assessment guide expects the period to balance work patterns against security
Testing of disconnect behavior	Internal engineers or an implementation partner	One-time per platform, repeated after changes	Number of session types (web, SSH, VPN, database, API) and whether tests can run in a non-production environment
Documentation of settings and procedures	Internal compliance staff or an implementation partner	One-time, then updated with each change	Depth of the system security plan and how many configuration baselines must reference the timeout values
Evidence upkeep after changes	Internal change management team	Recurring	Frequency of patches and configuration changes, and whether timeout settings are monitored automatically or checked by hand
Optional external review of design	Independent consultant or implementation partner, selected by the organization	One-time or periodic	Architecture complexity, cloud and SaaS dependencies, and whether the reviewer is independent of the implementer
Assessor time	Authorized assessor, paid by the organization	Recurring at each assessment cycle	Number of in-scope platforms sampled, evidence readiness, and whether logs and configuration exports are ready at assessment
Software tooling	Software vendors or open-source projects (license fees, if any, are set by the vendor)	Recurring if commercial, one-time setup otherwise	Choice of platforms, whether existing monitoring already captures configuration state, and SaaS session controls that the organization does not control

Which self-hosted open-source tools can produce session termination evidence

OPNsense is a BSD-2-Clause licensed firewall built on a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so the same rule can be reviewed across many systems. For SC.L2-3.13.9, the firewall can show that network connections are dropped or reset at the boundary, and that the rules behind those actions are documented. It cannot see an application's own idle timer, because a packet filter operates on network flows rather than user sessions.

Rule configuration as evidence: Exported rules and aliases show which flows are permitted and how long idle state is kept, where the firewall exposes those settings.
Log entries per rule match: Logging each rule match, and reviewing the live log view, gives a record of connections that were allowed, blocked or rejected.
Limits on application timeouts: A stateful table timeout is not the same as a session inactivity timeout enforced by a web or application server.
Scope of coverage: Only traffic that crosses the firewall is in view, so internal application sessions need evidence from the application or host.

Confirm with your team whether your firewall settings and logs meet the assessor's expectations for termination at the boundary, and whether the application layer needs its own evidence.

Common gaps that fail SC.L2-3.13.9

Most failures against SC.L2-3.13.9 come from paperwork and coverage rather than from missing technology. The gaps below cluster around three questions: has the organization decided on an inactivity period, does that decision reach every session-bearing system, and can the organization prove the timeout works today. Each card names the gap and the step that closes it.

No documented inactivity period

The requirement has three assessment objectives, and the first is defining an inactivity period. Assessors look for a written value, the systems it covers, and the reasoning behind it. The CMMC Assessment Guide Level 2 expects the period to balance user work patterns against security, so a bare number with no rationale invites questions. Close the gap by recording the chosen period in the system security plan or a configuration standard, with an approver and a review date. Ask the organization to confirm who owns that decision.

Timeouts set on some systems only

A timeout on the firewall console or the main application does not satisfy the requirement if the VPN concentrator, remote desktop gateway, database admin tool or file transfer service keeps sessions open indefinitely. Assessors test the systems that carry CUI sessions, so the inventory of session-bearing components is the starting point. Build that list from the boundary and the system security plan, then check each component's session settings against the documented period. Record exceptions with a reason and a compensating control, not a silent gap.

Web and cloud sessions that never expire

Browser sessions, single sign-on tokens and cloud console logins often refresh silently, so a session can outlive the user's activity by days. Session lifetime, idle timeout and token refresh behavior are separate settings, and each can keep a connection alive. Review the identity provider, the application framework and the cloud portal settings for idle and absolute session limits. Confirm that refresh tokens cannot extend an idle session past the documented period, and capture the configuration screenshots or exports that show it.

Timeouts that exist but are never tested

A configured value that nobody has exercised is weak evidence, because the assessment objective asks whether connections are actually terminated. SP 800-171A lists network disconnect procedures and the mechanisms that implement them as potential evidence, so assessors may test the behavior directly. Run a scripted test on representative systems: open a session, leave it idle past the period, then confirm the connection drops and the attempt is logged. Retain the test date, the tester and the output as evidence.

Default values with no decision record

A timeout that matches a vendor default is still a value, but without a decision record the assessor cannot tell whether the organization chose it. Evidence that shows only a default, such as an out-of-box configuration export, does not show that the organization defined an inactivity period. Write a short decision record for each system class that names the chosen value, the reason, the risk accepted and the approver. Where the period is adjusted later, add a dated change entry so the history is visible.

Drift from unmanaged configuration

Timeouts often drift when a system is upgraded, rebuilt or patched by someone who does not know the requirement. A correct setting on day one can be lost after a restore or a new host, and the gap is invisible until the next assessment. Use configuration management to enforce the timeout in a baseline, and use a compliance scanner to report failures. Fleet policies, for example, can show which devices pass or fail a yes or no check, so ask the team to confirm which checks run on which systems and how often.

Common questions about SC.L2-3.13.9

How much effort does SC.L2-3.13.9 take to meet?

The effort is usually modest per system but grows with the number of connection types you must cover. SC.L2-3.13.9 is worth 1 point under 32 CFR 170.24, so its weight in the score is small, but the work still has to be done and proven for every in-scope component. The main cost drivers are the number of systems and session types (web applications, remote access, administrative consoles, database and API connections), how many different platforms set timeouts, and how much documentation and testing your team needs to produce. Costs are mostly internal staff time plus any outside help you buy. Ask any partner to price the work by component inventory and to state which items are one-time (defining the inactivity period, configuring each component, writing the procedure) and which recur (periodic review, re-testing after changes).

How long does it take to configure an inactivity timeout?

No duration is published for this requirement, and the answer depends on your environment. Changing a timeout value on a single component is often quick. The longer work is deciding the inactivity period, which the CMMC Assessment Guide Level 2 says should balance user work patterns against security, then testing that the setting works across every connection type and documenting the result. Before you set a schedule, confirm the number of components, whether changes need a formal change control cycle under your configuration management process, and whether any system is vendor-managed. A partner should be able to give you a written schedule tied to the component list it reviewed.

Can an internal team meet SC.L2-3.13.9 without outside help?

Yes, many internal teams can. The organization owns its controls, so the requirement is yours to meet whether or not you hire help. An internal team needs to inventory the connections in scope, define an inactivity period with a documented rationale, configure termination at session end and after that period, test the behavior, and keep the records an assessor will review. Outside help makes sense when your team lacks time, when the systems are complex, or when you want an independent check before an assessment. Any implementation partner prepares systems and evidence; only an independent assessor or certification body issues an assessment result.

What should I ask an implementation partner before hiring one for SC.L2-3.13.9?

Ask for a written scope that names the systems, connection types and platforms covered, so the boundary of the work is clear before it starts. Useful questions include:

Which components will be configured, and who owns each setting after handover?
How will the inactivity period be documented, including the reasoning behind the chosen value?
What test evidence will show that connections terminate at session end and after inactivity?
Which deliverables are fixed in the quote, and what changes require a new scope?
How will the evidence be kept current when systems are upgraded?

DeployOpen works under fixed-scope engagements agreed in writing before work starts, and a quote follows from that scope. DeployOpen prepares systems and evidence for assessment but does not issue assessment results.

Can SC.L2-3.13.9 go on a POA&M?

Yes, under defined conditions. SC.L2-3.13.9 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110 (0.8). The POA&M closeout is due within 180 days. A POA&M is a commitment to finish the work, not a way to skip it, and you still need a credible plan. Confirm the current rules in the eCFR text of 32 CFR Part 170 and with your contracting officer, because CMMC implementation timing has been changing.

What will the assessor request as evidence for SC.L2-3.13.9?

The assessor will test three assessment objectives from NIST SP 800-171A (June 2018): that you defined an inactivity period, that network connections terminate at the end of sessions, and that they terminate after the inactivity period. Expect to show the configuration settings for each component, a procedure that describes network disconnect, audit records or logs that show the behavior, and the mechanisms that implement disconnect, which an assessor may test directly. Evidence must be in final form. Drafts do not count toward a MET result. Certification assessments are performed by C3PAOs, and the Department of War suspended Phase II on 13 July 2026, so confirm the current requirements on the DoW CIO About CMMC page before planning.

Does a firewall alone satisfy the connection termination requirement?

Usually not on its own. A stateful firewall such as OPNsense tracks connection state and can drop flows, but SC.L2-3.13.9 concerns the network connections tied to communications sessions in your systems, including application and administrative sessions that the firewall may not see. Check the timeout behavior of each application, remote access service and management interface, then use the firewall as one layer. Wazuh Security Configuration Assessment can scan endpoints against YAML policies that check configuration files and recommend remediation, and Fleet policies can ask yes or no questions of devices as osquery queries, which helps show which devices pass or fail a given setting. Both are evidence aids that you must configure and interpret yourself.

How DeployOpen prepares session termination for a CMMC assessment

DeployOpen works on SC.L2-3.13.9 as an implementation partner: we set and test the inactivity and session end settings in your environment and assemble the evidence an assessor will examine. Your organization owns the requirement and its inactivity period, and only an independent assessor can score it.

How we scope

Inventory the systems, applications, VPN concentrators and remote sessions that carry CUI and need termination settings.
Agree with your organization the inactivity period for each session type, balancing user work patterns against security.
Confirm in the written, fixed scope which platforms, configurations and evidence deliverables are included before work starts.

How we build

Configure session timeout and network disconnect settings on in-scope platforms, such as firewall and VPN session limits, using documented configuration baselines.
Write the parameter values into configuration records so the defined inactivity period is traceable to a single approved source.
Test each mechanism by opening a session, leaving it idle and confirming the connection ends at the defined point, with results recorded.

How we hand over

Deliver the configuration files, test records and audit log samples that show terminations occurring, mapped to the three SC.L2-3.13.9 assessment objectives.
Document the procedure for changing the inactivity period, including who approves changes and how changes are logged.
Provide a handover session so your staff can rerun the termination tests and explain the evidence to an assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so timeout settings are rechecked after platform changes.
Review evidence in final form before it is presented to your assessor, since drafts do not count toward a MET result.
Ask any assessor or certification body you engage to confirm which evidence they will accept for this requirement.