A 17-step checklist for taking a security programme from executive sponsorship to ISO 27001 or SOC 2 certification.
A cybersecurity governance framework is the set of decisions that says who owns security risk, how much of it the organisation is willing to carry, and how anyone would know whether the controls are working. It is not a tool purchase and it is not a policy document. It is the structure that makes every later security decision defensible.
Most programmes stall for the same reason: the controls exist but nobody agreed who owns them, what "acceptable risk" means in numbers, or which business outcome the whole exercise is meant to protect. Certification then becomes a scramble for evidence rather than a description of how the organisation already works.
The 17 items below are grouped into four phases, and the order matters more than the pace. Phase 0 exists because a programme without a sponsor and a stated risk appetite has no way to settle arguments later. The certification decision sits deliberately in Phase 3: choosing ISO 27001 or SOC 2 before you understand your own control gaps means picking a destination before you know where you are.
Tick items as you complete them. Progress is stored in your own browser and never leaves it, so nothing here is submitted to us or to anyone else.
Australian organisations should also read this alongside the APRA CPS 220, 230 and 234 guide if you are in a regulated financial services entity, since those standards impose their own timelines and board reporting obligations on top of anything below.
Lead GRC consultant
ISO 27001 or SOC 2
NIST CSF 2.0 / ISO 27001
Formalise the programme with a C-level sponsor and stand up a steering committee with the business units that will have to live with the decisions. Without a named sponsor, every contested control becomes a stalemate.
Run workshops with business unit leaders to document why certification is being pursued: a specific customer contract, a regulator, a tender requirement, or market access. A programme that cannot name its driver will be cut in the first budget review.
Facilitate a session with the steering committee or board to write risk appetite statements in measurable terms. "Low appetite for data loss" is not a statement; a stated tolerance for downtime, record exposure or regulatory finding is.
Perform a detailed gap analysis against NIST CSF 2.0 or the ISO 27001 structure, covering people, process and technology. Assess against one framework and map to the others, rather than running three assessments.
Set the organisational scope (whole entity, a division, a single product line) and the technological scope. Scope is the single biggest driver of certification cost, and it is far cheaper to narrow it now than during an audit.
Build the policy hierarchy properly: a Tier 1 charter, Tier 2 policies, and Tier 3 standards and procedures. A flat pile of policies with no hierarchy is the most common finding in a first internal audit.
At minimum: information security, risk management, access control, incident response and business continuity. Write them to describe what the organisation actually does, because an aspirational policy is an audit finding waiting to happen.
Implement a formal risk assessment and treatment methodology, such as ISO 27005 or the NIST Risk Management Framework, and stand up a risk register that is actually maintained rather than produced for audits.
Evaluate every risk against the appetite statements from Phase 0 and justify the treatment: mitigate, accept, transfer or avoid. This is where the earlier work pays for itself, because acceptance decisions stop being arbitrary.
Stand up risk treatment planning, third-party risk management, and compliance and assurance management. Third-party risk is the one most often deferred and the one most likely to produce an incident.
Create key risk indicators and key performance indicators that a board will actually read. Metrics that only a security team understands do not survive contact with a budget cycle.
Produce a RACI matrix naming who is responsible, accountable, consulted and informed for each control and process. Low priority to start, and the thing everyone wishes they had built earlier.
Integrate governance into business as usual: procurement, the software development lifecycle, and due diligence on acquisitions. Add role-based training so the framework survives the people who wrote it.
Decide on ISO 27001, SOC 2 or both, based on the business drivers from Phase 0 and the maturity you now have evidence for. The comparison below covers what each one is actually good for.
For ISO 27001, focus on evidence of the plan-do-check-act cycle. For SOC 2, focus on continuous evidence collection across the observation period, because a Type II report describes a window of time rather than a moment.
Run internal audits and management reviews at least annually, and feed the findings back into the risk assessment. A framework that is never revised is one nobody is using.
Review annually with the steering committee so the framework tracks the business rather than the version of it that existed when the programme started.
Choose after the gap assessment, not before. The right answer is usually dictated by who is asking for the evidence.