01
Make authority clear
Define who can isolate systems, disable accounts, engage specialists, communicate externally and accept operational risk.
Damocles incident readiness
Make the first hour of a security incident less chaotic.
Damocles Incident Readiness defines who decides, who communicates, what evidence is preserved, which systems can be isolated and how the organisation continues operating before pressure removes the time to work it out.
Roles and decision authorityPractical response playbooksEvidence and recovery readinessTabletop validation
The customer problem
A policy document is not an incident-response capability unless people can execute it under pressure.
Response plans often fail because contacts are outdated, authority is unclear, logs are unavailable, backups are untested, providers assume someone else is acting or technical and executive teams use different language.
Damocles turns likely incident scenarios into practical decisions, communication paths, evidence requirements and playbooks, then tests whether the people expected to respond can use them.
02
Preserve the evidence required
Identify logs, access, retention, time synchronisation and collection paths before an incident.
03
Test the plan before the incident
Use realistic tabletop scenarios to reveal decision, communication, provider and technical gaps.
Service coverage
Prepare the people, information and technical controls required to respond.
The scope can focus on one high-impact scenario or the broader incident-management operating model.
RL
Roles and decision authority
Executive, legal, communications, IT, security, privacy, provider and third-party responsibilities.
PB
Scenario playbooks
Practical steps for ransomware, account compromise, data exposure, service disruption and other agreed events.
CM
Communication and escalation
Contact trees, internal coordination, customer communication, provider escalation and decision triggers.
EV
Evidence and investigation
Logging, access, retention, time synchronisation, preservation and specialist investigation requirements.
BC
Continuity and recovery
Isolation, backup, restoration, alternate operation, critical dependencies and recovery decision points.
TT
Tabletop exercises
Facilitated scenarios that test decisions and handoffs rather than simply reading the plan aloud.
Technical assurance
Make your incident response plan usable under pressure.
Review plans, roles, access, evidence sources and decision paths through representative scenarios to identify gaps that could delay containment, investigation or recovery.
Roles and authority
Decision ownership, escalation and emergency authority.
Plans and playbooks
Practical guidance for representative incident types.
Detection and escalation
Triggers that move an event into coordinated response.
Technical access
Availability of systems, tools and emergency credentials.
Evidence readiness
Logs, timelines and preservation arrangements.
Communications
Internal, customer, supplier and adviser coordination.
Containment and recovery
Executable actions, dependencies and restoration priorities.
Exercises and improvement
Scenario walkthroughs, recorded gaps and owned actions.
What we actually test
Jump to full coverage matrix ↓Representative technical coverage with the evidence produced.
These are governed procedures from the service assurance profile—not generic marketing categories. The complete matrix below records applicability, access requirements and limitations for every coverage area.
Plans and playbooks
Damocles compares incident plans and playbooks with representative scenarios, technical dependencies, owners and current operating practice.
Roles and authority
Damocles interviews command and decision owners and walks through severity, authority, delegation and business-impact decisions.
Escalation criteria
Damocles traces escalation criteria from event recognition through technical, executive and external handoffs.
Internal and external communications
Damocles walks through internal and external communication paths, contact maintenance, approvals, alternates and out-of-band channels.
Technical access
Damocles asks responders to demonstrate access to representative security tooling, evidence stores, emergency accounts and required systems.
Evidence preservation
Damocles reviews collection, chain-of-custody, time, integrity, storage and transfer procedures for representative evidence types.
Showing 6 representative areas. The full governed matrix contains 13 coverage areas.
Standards and assurance coverage
See how this engagement is structured, classified and mapped before opening the full evidence matrix.
References are shown according to the role they play in the engagement. Methodologies guide testing, taxonomies classify findings, severity methods support consistent scoring, and control mappings connect scoped evidence to broader assurance work.
How testing is structured
Approved methodology, verification and testing guidance used to select and structure relevant procedures within the authorised scope.
How weaknesses and severity are classified
Findings are reported against the governed service coverage and customer impact. Separate classification references are shown only where they are part of the approved profile.
What maps into compliance and assurance work
1governed evidence mappings across 1 approved framework and 2 referenced controls.
1 contextual
Prudential Standard CPS 234 Information Security effective 1 July 2019Contextual
CPS 234 paragraph 35CPS 234 paragraph 36
Reviews and exercises the incident-response decision points, responsible roles, evidence dependencies, adviser paths and communication handoffs that an APRA-regulated entity may rely on when determining whether an information-security incident or material control weakness requires notification to APRA.
What the customer can use after the engagement
A readiness report with scenario results, material gaps, accountable actions and a prioritised improvement roadmap.
- Authorised scope and rules of engagement
- Coverage matrix
- Retest and residual-risk record
- + 3 additional controlled outputs
What this means: technical evidence may support risk, compliance and audit activity where the mapping is applicable. It does not by itself certify the organisation, establish complete compliance or assess controls outside the authorised scope.
Manual validation backed by controlled evidence.
Damocles reviews plans and evidence, interviews decision owners and responders, and observes a tabletop or simulation when included. Document presence, exercise performance and technical validation are reported distinctly; no exercise creates uncontrolled production impact or legal conclusions.
Evidence is mapped to the part of a control we can actually assess.
Directly assessed means the engagement tests the relevant behaviour. Supporting evidence means the result can contribute to a broader control assessment. Contextual references explain relevance without claiming that the control was tested.
All relevant frameworks
Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Information Security Manual June 2026Prudential Standard CPS 234 Information Security effective 1 July 2019Prudential Practice Guide CPG 234 Information Security published June 2019
Testing perspectives4 authorised viewpoints and access models
Plan and evidence reviewer
Compares plans, playbooks, contact paths and technical prerequisites with representative incident scenarios.
Incident commander or decision owner
Walks through authority, severity decisions, escalation and business trade-offs during interviews or exercises.
Technical responder
Demonstrates access to evidence and explains containment and recovery actions for the scenario.
Exercise participant and observer
Responds to approved injects while Damocles records decisions, timing, communication and unresolved dependencies.
Exact test coverage and evidence13 governed coverage areas
| Coverage area | What Damocles tests | Perspective and access | Evidence produced | References and limits |
|---|---|---|---|---|
| Plans and playbooks | Damocles compares incident plans and playbooks with representative scenarios, technical dependencies, owners and current operating practice. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for plans and playbooks. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to plans and playbooks. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Plans and playbooks when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled plans and playbooks; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Roles and authority | Damocles interviews command and decision owners and walks through severity, authority, delegation and business-impact decisions. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for roles and authority. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to roles and authority. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Roles and authority when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled roles and authority; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Escalation criteria | Damocles traces escalation criteria from event recognition through technical, executive and external handoffs. | Plan and evidence reviewer Incident plans and playbooks, the severity or classification model, escalation thresholds, role and contact matrix, representative scenarios or exercise injects, and applicable external-provider or adviser escalation paths. | Evidence records the documented escalation trigger, responsible role, expected notification or handoff, participant decision during a walkthrough or tabletop where performed, and identified gaps or ambiguities. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies when escalation decision-making is included in a readiness review, walkthrough or exercise. Limit: This assesses defined and exercised escalation behaviour but cannot prove every real incident will be recognised or escalated correctly; it provides no legal advice or guarantee of regulatory notification compliance. |
| Internal and external communications | Damocles walks through internal and external communication paths, contact maintenance, approvals, alternates and out-of-band channels. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for internal and external communications. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to internal and external communications. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Internal and external communications when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled internal and external communications; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Technical access | Damocles asks responders to demonstrate access to representative security tooling, evidence stores, emergency accounts and required systems. | Technical responder, Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for technical access. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to technical access. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Technical access when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled technical access; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Evidence preservation | Damocles reviews collection, chain-of-custody, time, integrity, storage and transfer procedures for representative evidence types. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for evidence preservation. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to evidence preservation. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Evidence preservation when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled evidence preservation; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Logging availability | Damocles reconciles scenario evidence needs with log sources, retention, access and known collection gaps. | Exercise participant and observer Log-source inventory, representative event identifiers, workflow records and responsible contacts. | Source-health state, event timestamps, investigation timeline and linked action or escalation record. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Performed when the relevant telemetry and analyst or customer workflow can be observed during the review window. Limit: Absent or delayed telemetry prevents a detection conclusion, and observation of one event cannot prove continuous detection of all attacks. |
| Containment dependencies | Damocles walks through containment decisions, authority and dependencies for accounts, endpoints, networks, cloud services and third parties. | Exercise participant and observer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for containment dependencies. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to containment dependencies. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Containment dependencies when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled containment dependencies; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Recovery dependencies | Damocles walks through restoration prerequisites, backups, validation, business acceptance and return-to-service decisions. | Exercise participant and observer Architecture, dependency list, monitoring view, authorised failover window and rollback owner. | A timestamped failover observation showing state, convergence, service checks, monitoring and recovery or rollback. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Performed only when a customer-approved recovery or failover scenario, observer and rollback window are available. Limit: The result covers the exercised failure mode; activity stops at the rollback threshold and does not predict every compound failure. |
| Legal and regulatory notification dependencies | Damocles identifies notification decision points, evidence, owners, advisers and time dependencies without providing legal advice. | Exercise participant and observer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for legal and regulatory notification dependencies. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to legal and regulatory notification dependencies. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Legal and regulatory notification dependencies when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled legal and regulatory notification dependencies; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Tabletop and simulation approach | Damocles delivers approved exercise injects and records participant decisions, timing, communications, assumptions and unresolved dependencies. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for tabletop and simulation approach. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to tabletop and simulation approach. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Tabletop and simulation approach when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled tabletop and simulation approach; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Lessons and improvement tracking | Damocles traces observations into owned improvement actions, due dates, acceptance evidence and subsequent review. | Plan and evidence reviewer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for lessons and improvement tracking. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to lessons and improvement tracking. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Lessons and improvement tracking when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled lessons and improvement tracking; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
| Document review versus exercise and technical validation | Damocles labels each conclusion as document review, interview, exercise observation or separately authorised technical validation. | Exercise participant and observer Assessment requires current plans, role holders, escalation paths, technical dependencies and exercise participation where agreed, selected specifically for document review versus exercise and technical validation. | Evidence records the plan section, role matrix, contact path, inject, participant decision, timeline, dependency or improvement action relevant to document review versus exercise and technical validation. | Incident Response Recommendations and Considerations for Cybersecurity Risk Management Revision 3 Applicability: Applies to Document review versus exercise and technical validation when the readiness capability is selected for document review, interview, walkthrough or exercise. Limit: The conclusion is limited to the sampled document review versus exercise and technical validation; evidence does not predict every incident and no legal conclusion or uncontrolled production action is provided. |
Framework and control mappings1 governed evidence mappings
| Framework and controls | Mapping type | What Damocles assesses | Evidence produced | Applicability and limits |
|---|---|---|---|---|
| Prudential Standard CPS 234 Information Security effective 1 July 2019 CPS 234 paragraph 35CPS 234 paragraph 36 | Contextual | Reviews and exercises the incident-response decision points, responsible roles, evidence dependencies, adviser paths and communication handoffs that an APRA-regulated entity may rely on when determining whether an information-security incident or material control weakness requires notification to APRA. | Scenario records, role and escalation evidence, notification decision points, communication dependencies, exercise observations and owned improvement actions where included. | Applies: Relevant only where an APRA-regulated customer includes regulatory-notification readiness within the authorised incident-response readiness scope. Limit: This is notification-readiness context only. Damocles does not provide legal advice, decide whether a matter is notifiable, guarantee notification timeframes or establish compliance with CPS 234 paragraphs 35 or 36. |
Assurance boundary: Damocles maps assessed coverage and observations to agreed objectives as traceable technical evidence. The review is not a certification, does not establish complete compliance, and does not confirm controls outside the authorised scope.
Report and evidence outputs6 controlled output types
Authorised scope and rules of engagement
Records authorised scope and rules of engagement produced from the authorised Incident response readiness review work.
Coverage matrix
Records coverage matrix produced from the authorised Incident response readiness review work.
Retest and residual-risk record
Records retest and residual-risk record produced from the authorised Incident response readiness review work.
Incident operating model
Records incident operating model produced from the authorised Incident response readiness review work.
Playbook assessment
Records playbook assessment produced from the authorised Incident response readiness review work.
Exercise decision timeline
Records exercise decision timeline produced from the authorised Incident response readiness review work.
What you receive
A readiness report with scenario results, material gaps, accountable actions and a prioritised improvement roadmap.
Common engagement options
Use readiness work to build, test and improve the response model.
The selected engagement depends on whether the customer needs a baseline, specific playbooks, an exercise or preparation for a managed response relationship.
GR
Incident-readiness gap review
Assess roles, contacts, playbooks, evidence, logging, backup, providers and current response capability.
PB
Playbook development
Create practical role, decision, evidence, communication and technical-action playbooks for agreed scenarios.
TT
Executive and technical tabletop
Run a realistic incident that tests leadership decisions, technical response, providers, communications and recovery.
RP
Ransomware and recovery readiness
Focus on isolation, identity, backups, restoration, communications and business-continuity decisions.
IR
Incident-response retainer preparation
Define access, contacts, evidence, authority, rates and mobilisation requirements before a live event.
RV
Post-exercise remediation review
Track and review the actions required after a tabletop, incident or readiness assessment.
Delivery lifecycle
Turn likely incidents into rehearsed decisions and owned improvement work.
The exercise or review is designed around the organisation’s systems, providers, data and operational dependencies.
01
Identify likely scenarios
Select the incidents most likely to create material operational, customer or regulatory impact.
02
Map people and dependencies
Document decision-makers, technical owners, providers, systems, data, contacts and authority.
03
Prepare the response model
Build or refine playbooks, communication paths, evidence requirements and recovery decisions.
04
Exercise the scenario
Run a realistic event with the people and providers expected to respond.
05
Record the gaps
Identify decision, access, evidence, process, provider and technical-control weaknesses.
06
Assign and review improvement
Create owners, due dates and follow-up evidence, then repeat the exercise where required.
What you receive
A response model the organisation can use during a real incident.
The output should make authority, communication, technical action and evidence expectations clear to the people who must act.
OM
Incident operating model
Roles, authority, contacts, escalation, provider responsibilities and decision structure.
PM
Scenario playbooks
Practical response steps, evidence, isolation, communication and recovery decisions for agreed incidents.
EC
Evidence checklist
Required logs, access, retention, preservation, time synchronisation and specialist collection needs.
CR
Communication plan
Internal coordination, executive updates, customer communication and provider contact pathways.
TR
Tabletop report
Scenario, decisions, observed strengths, gaps, unresolved questions and improvement priorities.
IR
Improvement register
Owner, priority, due date, required outcome and follow-up evidence for every material readiness gap.
What we need from the customer
A useful readiness exercise needs the people who actually make decisions and operate the affected systems.
The customer provides current contacts, incident policies, provider arrangements, system and data priorities, backup and recovery context, logging information and the executive and technical participants expected to respond.
Exercises are most valuable when participants can discuss real constraints openly. The purpose is to expose gaps and improve the model, not to produce a staged pass result.
What happens after delivery
The Incident Readiness engagement continues until the customer understands the work, the owners and the remaining risk.
The report or service record is the beginning of remediation, not the end of the engagement. These steps keep the outcome usable after formal delivery.
01
Confirm the material issues
Damocles walks the customer through the findings, evidence, affected scope, dependencies and uncertainty so there is agreement on what requires action.
02
Assign ownership
Each material recommendation is allocated to the team that can implement it, with a clear expected outcome and realistic dependency on other changes.
03
Sequence remediation
Quick risk reduction, structural change, compensating controls and longer-term engineering are separated so the customer can plan the work sensibly.
04
Capture implementation evidence
Configuration records, change references, screenshots, test results, source state or other agreed evidence are retained for later review.
05
Verify the result
Where included, Damocles reviews the changed state, performs a retest or reassessment, and records whether the original exposure is resolved, reduced or still present.
06
Record residual risk
Issues that cannot be fully removed remain visible with the accepted limitation, compensating control, review date and decision owner.
Commercial structure and change control
How a Incident Readiness engagement is scoped and kept commercially clear.
The proposal identifies the authorised scope, delivery method, assumptions, customer inputs, working window, deliverables, briefing, remediation support and any included retest or follow-up. Fixed-scope engagements are priced against that agreed boundary; retainers and managed services use the recurring quantity and service model stated in the schedule.
When the environment, target count, repositories, locations, access, service coverage or required evidence changes materially, Damocles records the impact before continuing. The customer can approve a variation, reduce the scope, defer the additional work or create a separate engagement. Hidden scope expansion is avoided because it produces poor testing and unreliable delivery dates.
Third-party licences, specialist platforms, travel, after-hours work, emergency response, remediation engineering and work outside the agreed deliverables are included only when listed in the proposal. Existing customer technologies can be used where they are supported and suitable; Damocles does not require a particular vendor simply to deliver the service.
Continuing the work in Guardian
Guardian can turn readiness gaps into visible improvement work and retain the evidence of completion.
Tabletop and readiness findings can become risks and All Actions with owners, due dates, required outcomes, supporting documents and review history.
This allows leadership to see which response weaknesses remain open, which providers or systems are affected and whether the follow-up work has been completed before the next exercise.
Questions buyers ask before engagement
Practical questions about Incident Readiness.
The final answer depends on the customer environment and scope, but these are the points that should be resolved before work begins.
Q1
How long will it take?
Timing depends on scope, access, environment stability, customer availability and the review depth required. The proposal states the expected delivery window and the assumptions that can change it.
Q2
Can the scope change after work starts?
Yes, but the change is recorded. Damocles explains the coverage, timing and commercial impact before additional work is performed.
Q3
Will Damocles work with our existing team or provider?
Yes. Internal teams, developers, cloud partners, infrastructure providers and MSPs can participate where responsibilities, access and communication paths are clear.
Q4
How are findings prioritised?
Priority considers practical exploitability or failure likelihood, exposure, affected business capability, data, privilege, dependency, available compensating controls and remediation effort.
Q5
Is remediation included?
Remediation guidance and handover are included as stated in the proposal. Implementation, managed change, emergency work and extensive engineering are separate unless expressly included.
Q6
How is closure verified?
Closure uses the method suitable for the issue: retesting, rescanning, code or configuration review, operational evidence, restored source health, tabletop follow-up or another agreed validation method.
Scope, assumptions and boundaries
Readiness work is not the same as an unlimited live incident-response service.
Live response, forensic acquisition, containment, legal advice, notification, recovery engineering, malware analysis and continuous on-call availability are included only where separately contracted.
An exercise does not certify that every incident will be detected, contained or recovered within a fixed period. It assesses the agreed scenario and the evidence available during the engagement.
Take the next practical step
Choose the incident scenario that would be most damaging or confusing today.
We will map the people, providers, evidence, systems and decisions required, then define the readiness review, playbook or tabletop exercise needed.