You know a security control is working when current evidence, read from the system that enforces it, passes a test against the state the control is supposed to be in. A clean audit report, a written policy or a green dashboard tile cannot tell you that on its own, since each describes an earlier moment or an intention. The test has to be repeated as the environment changes, because changes are what break controls that once passed.
That repeated test is the work of Continuous Control Assurance. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. The rest of this article explains what “working” means in NIST’s terms, the 5 kinds of change that break controls, and how to check between audits.
What does it mean for a security control to be working?
NIST gives the answer in 3 parts. Its guide to continuous monitoring, SP 800-137, quotes the definition of security control effectiveness from SP 800-53A: “the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.” The current assessment guide, SP 800-53A Revision 5, keeps the same 3 tests.
Each part is a separate check, and multifactor authentication for administrator accounts shows the difference.
- The control is implemented correctly when the identity provider holds a policy that requires a second factor for the administrator role.
- The control is operating as intended when that policy applies to every administrator account in scope, including accounts created last week, privileged service accounts and accounts in groups that someone excluded.
- The control is producing the desired outcome when sign-in records show administrator sessions completing a second factor, with no path around it.
A policy screenshot proves the first check. The second and third need the account list and the sign-in records, read as they are today.
How quickly can a control stop working after it passed?
A control can stop working as quickly as the system under it can change, which for a cloud setting or an identity group can be within a single deployment. No standard sets a shelf life for a passed test. NIST SP 800-137 describes a continuous monitoring program as one that helps ensure deployed controls “continue to be effective” in light of “the inevitable changes that occur over time”, and the catalog discussion of control CA-7 in NIST SP 800-53 Revision 5 notes that different types of controls may require different monitoring frequencies.
So the useful question is how fast the thing under each control changes. A firewall rule set that changes weekly needs a test that runs at least that often. A board-approved policy that changes once a year can be checked when it falls due.
The 5 kinds of change that break controls
The changes that turn a passed control into a failed one fall into 5 groups. Each maps to a family of controls in NIST SP 800-53 Revision 5 and to a control in CIS Controls v8.1, so the test for each one can be written against a public reference.
Configuration changes
A hardening baseline is overwritten by a new server image, a storage bucket is made public for a test, or a logging setting is switched off during a release. NIST control CM-6 asks an organization to document its configuration settings, to approve any deviation from them and to monitor and control changes to them. CIS Control 4 asks for the secure configuration of enterprise assets and software to be established and maintained.
The test compares each current setting with the documented baseline. A deviation with a documented approval is an exception with an owner, and a deviation without one is a failure.
Security posture changes
Posture changes when the tools that enforce and observe controls change. An endpoint agent stops reporting, a SIEM source goes quiet, or coverage drops after a migration. Nothing is misconfigured on the surface, and yet the controls that depend on those tools can no longer detect or block what they did last month.
The test reads coverage instead of settings: every asset in scope has a reporting agent, and every log source has sent data within the window its control expects. A posture change often shows up first as missing evidence, which is why the difference between a control failure and an evidence failure matters so much.
New assets
A new cloud account, a new SaaS application or an acquired subsidiary arrives, and every control that was tested against the old inventory is untested for the new asset. NIST control CM-8 asks for a component inventory that accurately reflects the system and includes all components within it. CIS Control 1 asks an enterprise to manage its assets actively so that it can “accurately know the totality of assets that need to be monitored and protected within the enterprise.”
The test compares the inventory with each control’s scope, and an asset outside the scope is a gap. DigitalXForce’s Attack Surface Manager runs agentless, API-based discovery and inventory across 9 asset classes, IT and OT, for this reason.
Identity and access changes
People join, move and leave, and accounts change with them. A new administrator account is created outside the joiner process, a service account is exempted from multifactor authentication during a migration, or a leaver’s account stays active. NIST control AC-2 asks an organization to monitor the use of accounts and to review accounts for compliance with its account management requirements at a set frequency, and CIS Control 5 covers the management of user, administrator and service accounts.
The test compares the identity provider with the rule and with the HR record. Every privileged account has a second factor and a named owner, and no active account belongs to someone who has left.
New vulnerabilities
A published vulnerability can make a correctly configured system exposed without any change on your side. NIST control RA-5 asks for scanning when new vulnerabilities that may affect the system are identified, and for remediation within response times the organization sets. Control SI-2 asks for security-relevant updates within a set period after their release, and CIS Control 7 asks for vulnerabilities on all enterprise assets to be assessed and tracked continuously.
The test reads each open vulnerability against its remediation deadline. A finding past its deadline is a failure of the patch management control, whatever the scanner’s severity label says.
Control failure or evidence failure?
When a test does not pass, the first question is whether the control failed or the proof failed. The two need different owners and different fixes, and a program that mixes them either sends engineers after controls that are fine or reports controls as working when nobody can see them.
| Question | Control failure | Evidence failure |
|---|---|---|
| What happened? | The control is not in the state it should be in, such as an administrator account without a second factor. | The proof is missing, stale, incomplete or unreliable, so nobody can tell what state the control is in. |
| What usually causes it? | A change in the environment broke the control. | A connector lost access, an agent stopped reporting, an export covered part of the population, or the last reading is older than the control’s schedule allows. |
| What should the result say? | The result should record a failure. | The result should record that the test cannot decide, and it should never record a pass. |
| Who fixes it? | The control owner fixes the control, and the control is tested again. | The owner of the evidence source restores the feed, and the control is tested again. |
| What does it mean for risk? | The risk the control treats is exposed until the retest passes. | The exposure is unknown, and for a high-risk control an unknown deserves the same urgency as a failure. |
NIST sets the same standard for assessments. Its discussion of control CA-2 in SP 800-53 Revision 5 asks organizations to ensure that assessment results are current and relevant to the determination of control effectiveness. A result that is not current has not been shown to be a pass.
How to check your controls without waiting for the next audit
The method below works with any tooling. It is the practical form of Continuous Control Assurance (CCA), and it answers the question for each control on the control’s own schedule.
- Write down the expected state of each control in terms a system can check, such as “every administrator account in the identity provider requires a second factor”.
- Name the system that holds the evidence and read it directly, across every item in scope. NIST SP 800-53A describes the test method as comparing the actual state of an object with its desired state or expected behavior.
- Set a test frequency for each control from how fast the system under it changes.
- Record every result with the time its evidence was read, and record missing or stale evidence as undecided.
- Send every failure to a named owner, and test the control again after the fix.
- Compare the asset inventory with each control’s scope on a schedule of its own, so new assets enter the tests.
Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls. It is the capability within CCA that keeps the evidence behind steps 2 to 4 current between tests. The Continuous Control Monitoring page explains how it works, and the Continuous Control Assurance page sets out the full chain from requirement to retest. Where monitoring stops and assurance starts is the subject of Monitoring Detects. Continuous Control Assurance (CCA) Validates.
How DigitalXForce runs this
Enterprise Security Risk and Posture Management (ESRPM) is the DigitalXForce module that runs configuration checks, operational insights and deployment benchmarking across IAM, SIEM, cloud, OT and IoT, SecOps and enterprise systems through 250+ technology integrations. The ESRPM module covers the configuration, posture and identity changes above. The AI-Powered Risk Management and Automated GRC module maps each tested control once to 50+ compliance frameworks, so one result answers every framework that requires the control. The FAQ answer on how controls are validated describes the cycle in 2 paragraphs.
Where DigitalXForce is not the answer
A startup or small company preparing its first SOC 2 report can start with DigitalXForce Lite, which runs the same platform in the cloud with the same functionality and a faster deployment. A team with no asset inventory or no central identity provider should fix those first, since every test in this article reads from them.
Questions about whether security controls are working
How do I know whether my security controls are actually working?
A control is working when current evidence, read from the system that enforces it, passes a test against the control’s expected state. NIST describes control effectiveness as the extent to which a control is implemented correctly, operating as intended and producing the desired outcome. Each of those 3 tests needs its own evidence, and the test has to be repeated as the environment changes.
How quickly can a control become ineffective after it was validated?
A control can become ineffective as quickly as the system under it can change, and no standard sets a fixed shelf life for a passed test. A cloud setting or an identity group can change within one deployment, while a board-approved policy may change once a year. The test frequency for each control should follow how fast its system changes.
How can a CISO verify controls without waiting for the next audit?
Write the expected state of each control in terms a system can check, read the evidence from the system that enforces it across everything in scope, and test on a schedule set by how fast that system changes. Record every result with the time its evidence was read, send failures to a named owner and test again after the fix. Continuous Control Assurance (CCA) is the discipline that runs this cycle.
How do configuration changes affect controls that already passed?
A configuration change can move a control away from its documented baseline the moment it is made, and the earlier pass says nothing about the new state. The control has to be tested again against the baseline. A deviation with a documented approval is an exception with an owner, and one without approval is a failure.
How do new assets affect Continuous Control Assurance (CCA)?
Every control tested against the old inventory is untested for a new asset until the asset enters its scope. Continuous Control Assurance (CCA) compares the asset inventory with each control’s scope, so an asset outside that scope shows up as a gap. An accurate, current inventory is the precondition for every other test.
What is the difference between a control failure and an evidence failure?
A control failure means the control is not in its expected state, such as an administrator account without a second factor. An evidence failure means the proof is missing, stale or incomplete, so nobody can tell what state the control is in. The first is fixed by the control owner, the second by the owner of the evidence source, and neither should ever be recorded as a pass.
How do vulnerabilities affect control assurance?
A newly published vulnerability can expose a system that was configured correctly, without any change on the organization’s side. The patch management control is tested by reading each open vulnerability against the remediation deadline the organization set. A vulnerability past its deadline is a control failure, whatever severity label the scanner gives it.
Sources
- NIST, SP 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems and Organizations, January 2022, section 2.4.2, for the test method. https://csrc.nist.gov/pubs/sp/800/53/a/r5/final, read 26 September 2026.
- NIST, SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, September 2011, chapter 1 and its footnote 3, for control effectiveness and the inevitable changes over time. https://csrc.nist.gov/pubs/sp/800/137/final, read 26 September 2026.
- NIST, SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations, controls AC-2, CA-2, CA-7, CM-6, CM-8, RA-5 and SI-2, read from NIST’s catalog release 5.2.0. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final, read 26 September 2026.
- Center for Internet Security, CIS Controls v8.1, Controls 1, 4, 5 and 7. https://www.cisecurity.org/controls/v8-1, read 26 September 2026.
Do this once instead of every audit.
Every step above can be done by hand. DigitalXForce does them continuously, maps the result to 50+ frameworks once, and keeps the evidence current between audits. A 30 minute walkthrough on your own framework set shows what that removes from your calendar.
