Cybersecurity program
This domain tests how the security function is governed, resourced, operated, and improved: who owns risk, how policies become practice, and how the program proves it works.
Program architecture and governance
- Accountable ownership: an executive sponsor and a named owner for each risk; a security leader coordinates but does not absorb every risk.
- Risk management cycle: identify, assess, treat, accept, and monitor. A risk register records owner, treatment, due date, and residual risk.
- Policy hierarchy: policy states intent, standards set requirements, procedures describe steps. Map them to a framework such as NIST CSF or ISO/IEC 27001 for structure, not a substitute for judgment.
- Scope and inventory: define the program boundary and maintain an asset inventory; unknown assets cannot be protected or measured.
Operating the program
- Deliver role-based awareness and phishing simulation with measured follow-up, not annual slideware.
- Run incident response through prepare, detect and analyze, contain, eradicate, recover, and post-incident review.
- Maintain business continuity and disaster recovery plans from a business impact analysis with defined RTO and RPO.
- Tier third parties by data access and criticality, then apply due diligence, contract clauses, and ongoing monitoring.
- Track a small set of risk-based metrics and audit against them; management review closes the loop.
Worked example
A SaaS company wants certification. It starts with an asset inventory and risk assessment, not a tool purchase. Risks are assigned owners; policies and standards address the highest risks and map to the chosen framework. A tabletop exercise tests the incident response plan; vendors are tiered and reviewed; a dashboard tracks overdue treatments and backup restore success. Internal audit finds gaps, and management review assigns dated fixes. The reasoning is sequence: scope and risk define which controls and evidence matter, and testing proves they operate.
Traps that cost marks
- Buying tools before defining scope and risk.
- Publishing policies that no process enforces.
- Treating an untested incident or recovery plan as complete.
- Keeping a static risk register with no owners or dates.
- Reporting activity metrics that do not show risk reduction.
- Treating certification as the end state rather than evidence of an operating program.