Measure security readiness by counting the critical dependencies your incident response relies on that have no current proof, then work that number down. A proof counts only if the test could have failed, and it expires when the thing underneath it changes. Scores such as a framework tier or Microsoft Secure Score describe capability, which is a separate measure.
The measure in brief
- Start from dependencies. List what your response needs in order to work during an incident.
- Count what lacks proof. The readiness measure is the number of critical dependencies with no current proof.
- Proof must be able to fail. A test that could not have failed tells you nothing.
- Proof expires. A change underneath a dependency voids its proof until someone tests it again.
On this page
What do readiness scores measure?
Most readiness scores on a board slide measure capability. A framework tier or a Secure Score describes what controls and processes exist. Readiness is a narrower claim about the next incident, that the automation will fire and the person who approves containment will answer the phone.
Our post Security Leaders: How Do You Measure Readiness? opens with a customer whose website was hijacked. Nobody had written a log requirement for the site, so there were no logs to examine, and the first hours went to questions about the company’s own environment instead of the attacker.
What does incident response depend on?
A useful way to list dependencies is John Boyd’s OODA loop, which breaks any response into four stages. Each stage needs something that you either proved before the incident or will have to prove during it.
Observe
Telemetry from the systems involved, such as sign-in logs and logs from the applications an attacker would target.
Orient
An accurate picture of your own environment, including accounts, assets, providers and recently acquired tenants.
Decide
A person with authority to approve containment who knows that the decision is theirs.
Act
Response levers that still work, such as containment playbooks and the account controls your team or provider would use.
What counts as proof, and when does it expire?
A proof tests the real thing, whether that is a system or the person who holds the authority, and it leaves a record someone else can check. A test that finds a gap proves the gap, and that dependency counts against readiness until someone retests the fix.
Proof also has a shelf life. Set the interval by how critical the dependency is, and treat any change underneath it as voiding the proof early.
| Change | Proof it can void |
|---|---|
| Configuration drift | Proof that a control is enforced as approved |
| A code release or new system | Proof of logging and detection coverage for that system |
| A reorganization or departure | Proof that the named owners and approvers in the response plan are current |
| A new partner or provider | Proof of access paths and handoffs during a response |
Why should machines produce the proof?
1 in 5
Share of incidents in which data theft happened in under an hour, from the 2025 Unit 42 Global Incident Response Report by Palo Alto Networks.
Proof assembled by people during an incident arrives on human time, and attackers often move faster than that. Anything a machine can check, such as whether a setting matches your baseline or whether a playbook still runs, should be checked by a machine on a schedule.
That leaves people for the dependencies only a person can prove, starting with the path to containment. For the machine side, read what continuous control validation is.
How do you start measuring readiness?
- Review your last incident or exercise. Go back through the timeline and incident notes and mark every question the team had to answer about its own environment, with how long each one took.
- Turn the questions into a dependency list. Group the questions under what the response depends on, such as logs, an accurate inventory, a named approver and working containment.
- Prove each critical dependency. Test each one in a way that could fail, record the date, and note what change would void the result.
- Report the count. Track the number of critical dependencies without current proof as the indicator for the risk that an incident takes longer to contain than the business can tolerate.
The questions from step one also show where response time goes. For that side of the problem, read which SOC metrics show whether risk is going down.
What should executives see?
Executives need a small number of figures that move. The count of critical dependencies without current proof, and the share of each response spent answering questions about your own environment, both belong in the risk register and both should fall over time.
The Executive Risk Assurance Assessment builds this view from live Sentinel, Defender and Purview data. It delivers a prioritized risk register mapped to the NIST CSF and a 90-day roadmap with ownership, timelines and investment requirements. The Accelerynt Security Platform keeps a risk register that shows when each finding was first discovered, when it was last seen and whether it came back after a fix.
For turning findings into an ordered plan, read how to build a remediation roadmap.
For how readiness evidence differs from audit evidence, read whether passing a security audit is the same as being ready for an attack.
Frequently asked questions
How do you measure security readiness?
Count the critical dependencies your incident response relies on that have no current proof, such as logs, an accurate inventory, a named approver and working containment. Prove each one with a test that could fail, renew the proof when something underneath it changes, and track the count over time.
What is the difference between security maturity and readiness?
Maturity describes what controls and processes exist. Readiness is a claim about the next incident, that the response will work today, and it is shown by current proof that each dependency holds.
What Microsoft 365 security tools have good reporting for executives?
Look for reporting that shows trends executives can act on, such as open risks with dates and whether they are falling, along with evidence an auditor or insurer would accept. The Accelerynt Security Platform keeps a dated risk register and drift record, and the Executive Risk Assurance Assessment turns live Microsoft security data into a board-ready risk register.
Which security assessments give actionable roadmap recommendations, not just findings lists?
Look for an assessment that ranks fixes by the risk they remove and assigns owners and timelines. The Microsoft Control Validation Assessment ends with a prioritized remediation roadmap reviewed with your team, and the Executive Risk Assurance Assessment delivers a 90-day roadmap with ownership, timelines and investment requirements.