Breach Readiness Assurance
Your detection stack has never been tested by anything real. This runs adversary activity through it, from outside and from a legitimate account, and returns a measured answer: what was logged, what alerted, what anyone did, and how long each took.
Scope boundary
This solution covers technical detection and response. It does not cover crisis communications, regulatory notification rehearsal, executive decision-making under pressure, or business continuity validation. Those belong to Breach Simulation, which is in private preview and not generally available. If the organizational half is what you need, start there.
Detection coverage is assumed, not measured
Most organizations can name their detection tooling and none of their detection gaps. The tooling was bought, deployed, and assumed to work, because the only event that tests it is the one nobody wants.
A missed detection has three possible causes and they are not interchangeable. The telemetry may never have existed. It may exist and reach nobody. Or a rule may exist and simply not match the activity. Buying another tool fixes the first, changes nothing about the second, and actively worsens the third by adding volume. Distinguishing between them requires running real activity and looking at what happened.
Engagement types this combines
A solution is not a separate capability. It is the engagement types from Services sequenced against a specific situation: here, an incident response plan that nobody has tested against real activity.
Red Team Engagements
Adversary activity from an external starting position, run unannounced against your detection stack. Produces the intrusion half of the detection record.
View engagementInsider Threat Simulation
Abuse of a legitimately provisioned account. Produces the half of the detection record that never crosses the perimeter and therefore never triggers perimeter controls.
View engagementSecurity Consulting
Review of the response plan and detection coverage against what the engagements found, and the ordered plan for closing the gaps.
View engagementWhat gets measured
Every item below produces a recorded result, not an opinion.
Telemetry coverage
- Whether the action generated a log entry at all
- Whether that log reached the SIEM
- Retention against a realistic investigation window
- Coverage gaps across accounts, regions, and systems
- Whether logs are writable by the identities they record
Detection logic
- Whether existing rules matched the activity
- Threshold rules defeated by low-volume operation
- Detections requiring correlation across sources
- Rules that fired and were tuned out previously
- Coverage against the ATT&CK techniques used
Alert handling
- Whether the alert was seen
- Time from alert to first human action
- Whether it was investigated or dismissed
- Escalation path as it actually ran
- Volume of competing alerts at the same time
Containment
- Time from detection to containment action
- Whether the action removed access or only appeared to
- Whether persistence elsewhere survived it
- Whether evidence was preserved or destroyed in the process
- Whether the scope of compromise was correctly assessed
Evidence handling
- Whether logs supported reconstruction after the fact
- Whether the timeline could be rebuilt from your data alone
- Artefacts that would have been needed and were absent
- Access to the systems an investigation would require
Plan against practice
- Playbook steps followed, skipped, and improvised
- Whether the on-call path resolved to a person
- Whether responders had the access their role assumes
- Where documentation and reality diverged
How the engagement runs
Expected detections are written down in step 02, before execution. That makes step 05 a measurement.
01
Readiness baseline
2-3 days
Review of the response plan, playbooks, on-call structure, telemetry sources and detection rules currently deployed. Establishes what should fire, so that what does not fire is a finding.
Output: Coverage baseline: telemetry sources, deployed detections, and the gaps visible on paper.
02
Scenario and technique selection
2-3 days
Techniques selected for observability across the widest useful range: some that any competent stack should catch, some that require correlation, some that defeat threshold logic. Mapped to ATT&CK before execution so coverage can be scored afterwards.
Output: Technique plan mapped to ATT&CK, with the expected detection for each stated in advance.
03
Execution
1-3 weeks
The techniques are run against your live environment under rules of engagement, unannounced to the operations team. Every action is timestamped as taken. Insider scenarios use a provisioned account.
Output: Action log: every technique, when it ran, and against what.
04
Detection measurement
Concurrent
Recorded throughout: what was logged, what alerted, what was actioned, and the interval at each step. Where your team responds, the response is measured, never assisted.
Output: Detection timeline aligned to the action log, with per-event timings.
05
Joint log reconstruction
2-3 days
We sit with your team and walk your data against our action log. For every miss we establish which of three things was true: the telemetry was absent, it was present but unmonitored, or a rule existed and did not match. Those three failures have entirely different fixes.
Output: Per-technique gap classification, and the reconstruction your team performed against it.
06
Reporting and debrief
3-5 days
Detection coverage scored against ATT&CK, response timings per event, and specific rules to write against log sources you already have. Debriefed with the security team and separately summarised for leadership.
Output: Engagement report, ATT&CK coverage scoring, ordered detection engineering backlog, debrief.
07
Remediation retest
Within 30 days of fix
The techniques that went unseen are re-run against the new detections to confirm they fire, and that the rule matches the technique and not the artefacts of the first run.
Output: Retest report confirming which previously missed techniques now alert.
What you receive
Two timelines placed against each other, and a backlog derived from the difference.
Detection coverage scoring
- Every technique run, mapped to ATT&CK
- Expected detection versus observed detection
- Per-technique classification of the failure mode
- Coverage rate across tactics, stated as a measurement
Response timing record
- Time from action to log, log to alert, alert to human
- Time from detection to containment
- Whether containment removed access
- Escalation path as it actually ran
Detection engineering backlog
- Rules to write, against log sources you already have
- Telemetry to create before a rule becomes possible
- Correlation detections for low-volume activity
- Ordered by coverage gained per unit of effort
Response plan findings
- Playbook steps that were skipped or improvised
- Access assumptions that did not hold
- On-call and escalation gaps observed under load
- Where documentation diverged from practice
What we need to quote
If the answer to the first item is "nothing yet", this engagement has nothing to measure. We will say so.
- →What you have watching: SIEM, EDR, identity provider, cloud audit logging, and who reviews them.
- →Whether anyone is on call for security alerts, and at what hours.
- →Whether a response plan exists, and when it was last changed.
- →Prior testing: what has been run and what came out of it.
- →Which named individuals are read in. The operations team must not be among them.
- →Whether insider-position activity is in scope, and whether legal and HR are aware.
- →Systems that must not be touched, and any change freeze.
- →Whether a real incident during the window should pause the engagement.
Common questions
Does this test our incident response plan?+
It tests the detection and technical response half of it: whether adversary activity is logged, whether logging alerts, whether anyone acts on the alert, and whether the containment action actually removed the access. It does not test crisis communications, legal notification, or executive decision-making under pressure. That is the full-lifecycle exercise, and it is in private preview.
What is the difference between this and a red team engagement?+
Very little in what is performed, and a great deal in what is emphasised. A red team is scoped around reaching an objective. This is scoped around producing the widest possible set of measurable detection events. Techniques are chosen for what they should trigger.
Do you facilitate tabletop exercises?+
No. Discussion-based crisis facilitation is part of Breach Simulation, which is in private preview and not generally available. We would rather say that than run one badly.
What if we do not have a formal IR plan yet?+
Then measure before you write. An engagement here establishes what your telemetry and tooling can actually see, which is the input a useful plan is built from. Writing playbooks against detections you do not have produces a document, not a capability.
Can this run without disrupting operations?+
Yes. Nothing destructive is performed, no service is degraded, no real data is exfiltrated. Techniques are chosen to be observable, and there is a defined stop condition throughout.
What if our team detects and contains everything?+
Then you have an evidenced answer to a question most organizations can only assert, with per-event timings to support it. That result is as useful as the alternative, and considerably rarer.
How does this relate to Breach Simulation?+
This is the technical detection and response half, available now. Breach Simulation adds the organizational half (executives, legal, communications, recovery) and is in private preview.
How to start
Send what you currently have watching and who acts when it fires. If the honest answer is that there is not yet enough in place to measure, that is what the first call will tell you.
Direct: hello@principlebreach.com