A current state assessment is a structured review of what the organisation can actually do today, across controls, process, visibility, and ownership. In identity security, it prevents teams from assuming they have governance capabilities that exist only on paper or in individual teams’ memories.
What a current state assessment actually measures
A current state assessment answers a simple but easy-to-misjudge question: what is really in place today, not what the programme intends to build next. It compares lived reality across controls, process, ownership, and visibility, which is why it is useful before prioritisation, remediation, or maturity planning.
The value is in separating documented capability from operational capability. A team may have policies, diagrams, and assigned owners, yet still lack evidence that the control works consistently or that the right people can explain and execute it when needed.
Why current state assessments matter in security programmes
In cybersecurity, the current state is the baseline for every later decision. Without it, teams tend to overestimate coverage, underestimate dependencies, and assume that a control exists simply because a standard or workflow says it should.
This is especially important in identity-heavy environments, where NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both depend on accurate knowledge of what is actually operating, not just what is documented.
For cloud and vendor-heavy environments, the same assessment often needs to reflect shared responsibility and external dependencies. A CSA Cloud Controls Matrix view is useful when the real question is whether control ownership, implementation, and evidence line up across the environment.
What should be included in the assessment
A useful current state assessment usually covers four things: control design, operational execution, ownership clarity, and observability. Control design asks whether the right control exists. Operational execution asks whether it is consistently performed. Ownership asks who is accountable. Observability asks whether the organisation can verify the control and notice when it fails.
The same structure applies across access, logging, configuration, resilience, and lifecycle processes. If a team cannot show current evidence, name the owner, or explain the operating process, the assessment should treat that as a gap in current state rather than a minor documentation issue.
In practice, this is where SOC 2 Trust Services Criteria can help when the assessment feeds customer assurance or service-provider governance, because current state needs to be demonstrated, not merely asserted.
How to read the results
The output of a current state assessment should be treated as a decision input, not a score for its own sake. Strong findings tell you where the organisation already has working capability, where controls exist only partially, and where ownership or evidence is too weak to trust the stated posture.
A good assessment also distinguishes absence from immaturity. A missing control, a control with no evidence, and a control that exists but is inconsistently run are different problems, and each one changes the remediation path.
Because the assessment is a baseline, it should support future comparison. The most useful result is not a report full of observations, but a credible map of what the organisation can prove, operate, and sustain today.
Risk and Threat Considerations
A poor current state assessment creates false confidence. Teams may believe a control is effective, when in reality it is undocumented, inconsistently executed, or owned by a person rather than a process, which leaves gaps that attackers and failures can exploit.
Failure mechanism: The organisation infers readiness from policy, tooling, or local knowledge instead of verifying that controls, ownership, and evidence work together in practice. That gap can hide privilege sprawl, missing monitoring, weak recovery paths, or control drift until an incident exposes it.
Impact: The result is slower detection, weaker accountability, and a higher chance that security decisions are made on incomplete information. In identity and access programmes, this can translate into excessive access, stale permissions, or unmanaged exceptions that persist longer than expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — Mission Objectives and Stakeholder Expectations | Current state assessments establish the real operating baseline for governance decisions. |
| Recommendation — Document the actual baseline before planning target-state improvements. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | A current state assessment is a direct control-assessment activity for verifying implementation. |
| CA-7 — Continuous Monitoring | Current state must stay current as control performance and evidence change over time. | |
| Recommendation — Assess implemented controls against expected outcomes and evidence. Continuously monitor control status and update the baseline when conditions change. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | A current state review depends on knowing what exists and who owns it. |
| A.5.36 — Compliance with policies, rules and standards for information security | The assessment checks whether stated governance and controls are actually being followed. | |
| Recommendation — Maintain an accurate inventory so assessment scope reflects reality. Verify that operational practice matches policy and standards. | ||
Practitioner Guidance
Why practitioners should care: A current state assessment is most valuable when it becomes the source of truth for planning and prioritisation. Treat it as a working inventory of reality, not a compliance artefact or a one-time discovery exercise.
What to watch for: Look for gaps between policy and practice, especially where ownership is unclear, evidence is manual, or a control depends on a single team member’s memory. Those are usually the places where the current state is least trustworthy.
Practitioner takeaway: If the assessment cannot be defended with evidence, it is not yet a reliable baseline.
Related resources from NHI Mgmt Group
- How should security teams investigate cloud incidents when the current configuration no longer matches the failure state?
- Who is accountable when MFA evidence does not match the current GCC High tenant state?
- What breaks when a SIEM can only show events and not current exposure state?
- What breaks when posture management only shows current-state AI controls?