Most organisations do not “choose” to accept cyber risk. For boards, board cybersecurity risk should be a key consideration, but often they accept it by default, usually during procurement and delivery, not in BAU. Then, when something goes wrong, leadership has to defend a decision they never consciously made.
If that sounds familiar, your problem is not a lack of effort. It is a lack of mechanism. Without a repeatable mechanism, cyber becomes vibes-based governance: confidence feels high, everyone pushes to hit go-live, and missing evidence gets brushed aside as “we’ll fix it later”.
The hard truth is simple: if evidence is missing, the risk is already being accepted. The only question is whether you can prove it was explicit, owned, time-bound, and funded.
This article lays out a practical model called Six Security Gates. The goal is not more paperwork. The goal is enforceable decision points, with named owners and an audit-ready evidence trail that holds up under regulator, insurer, or board scrutiny.
Why leadership teams get trapped in “implicit risk”
A good security program is not measured by how many controls you bought. It is measured by whether you can answer, quickly and credibly:
- What are we accepting?
- Who owns it?
- What evidence supports the decision?
- What is the plan and deadline to reduce it?
In Australia, cyber incidents keep climbing, and attackers keep picking the boring path: phishing, credential abuse, and third-party pathways. If you are still relying on informal approvals, you are creating the perfect conditions for a bad outcome and a weak defence.
The gap is nearly always governance, not intent. Leaders do not lack care. They lack an enforceable operating model that forces clarity at the moments where risk gets locked in.
If evidence is missing, the risk is already being accepted. The only question is whether it is explicit and defensible.
The Six Security Gates model (what it is, and why it works)
A “gate” is a point in the lifecycle where a decision is made that has long-term security consequences. You proceed when the minimum evidence exists, not when confidence feels high.
The six gates are:
- RFP and Selection
- Vendor Solution Context
- Contractual Obligations
- Design and Integration
- Pre Go-Live
- BAU Handover
This works because it targets where risk becomes expensive to change. The earlier the gate, the cheaper and faster it is to fix. We address each one of them below; but before that…
First, define materiality so you do not gate everything
If you try to apply gates to every initiative, you will fail. Leaders will treat it as bureaucracy and route around it.
Start by defining “materiality” triggers. For example:
- High spend, or strategic vendor dependency
- Customer-facing or internet-exposed systems
- Regulated or sensitive data
- New external access, integrations, or hosting
Materiality is how you keep governance serious without becoming slow.
Then, assign decision owners so accountability cannot drift
You need a minimum set of decision owners for material initiatives. A workable baseline is:
- Exec sponsor (CIO/COO): go/no-go accountability
- Security lead: evidence quality and exceptions management
- Procurement and Legal: supplier controls and enforceability
- Ops owner: supportability and BAU readiness
This is not about blame. It is about preventing the classic failure mode where everyone assumes someone else has it covered.
What each gate demands (the leadership-grade version)
Gate 1: RFP and Selection
This is where “we bought a brand name” becomes a substitute for due diligence.
At this gate, demand:
- A scored security requirement set in the RFP (not an afterthought)
- A shared responsibility matrix (vendor, customer, shared)
- Fit checks for identity integration, logging, monitoring, and support model
- A plain-English residual risk statement before you select
Gate 2: Vendor Solution Context
This is where you stop assuming certifications equal coverage for your use case.
At this gate, demand:
- Certification scope checks against your exact deployment
- Documented high-level architecture and data flows
- Known risks logged with an owner, treatment, and due date
Gate 3: Contractual Obligations
This is where you either gain leverage or lose it for years.
At this gate, demand:
- Measurable security obligations, not “reasonable endeavours”
- Remediation SLAs and reporting cadence
- Clear incident notice and cooperation terms
- Audit rights and a right to test
- Data handling clarity (residency, access, subprocessors, exit)
Gate 4: Design and Integration
This is where insecure defaults get baked in and become “too hard” later.
At this gate, demand:
- Security non-functional requirements that are owned and tracked
- Early design reviews with evidence captured
- Testable acceptance criteria
- A decision log plus an exceptions register
Gate 5: Pre Go-Live
This is where go-live pressure creates permanent exceptions if you let it.
At this gate, demand:
- Evidence that critical controls exist and are tested
- Residual risk explicitly accepted, in plain language
- Exceptions that are owned, time-bound, and funded
Gate 6: BAU Handover
This is where many “security incidents” are really operational failures: patching gaps, missing runbooks, and unclear ownership.
At this gate, demand:
- Named operational ownership
- Monitoring, alerting, and escalation tested end-to-end
- Enforced remediation cadence (patching, cert and key rotation)
- Handover as a gated deliverable, not an optional task
A 30-60-90 rollout plan that will not die in committee
You do not need a 12-month transformation plan. You need two pilots and a weekly cadence.
Days 0-30 (Build the mechanism): Create the gate policy, set materiality thresholds, name decision owners, and build minimum viable templates: RFP scorecard, risk memo, exceptions register, BAU handover pack.
Days 31-60 (Pilot on real work): Run Gates 1-3 on a procurement pilot. Retrofit Gates 4-6 on a delivery pilot. Train Procurement, PMO, Legal, Ops, and Architects. Start a weekly gate cadence.
Days 61-90 (Scale and lock it in): Embed gates into PMO stage gates. Produce a monthly board pack showing decisions, residual risk, and exception ageing. Run assurance sampling on evidence packs and test decision-making under pressure with a tabletop exercise.
What to measure (and what to delete)
Track adoption and defensibility:
- % of material initiatives using the gates
- Exception ageing by owner
- Time from issue raised to decision made
- Residual risk accepted (count and trend)
- Incidents linked to delivery or handover gaps
Vanity metrics do not protect leaders. Evidence does.
If a metric cannot drive a decision, remove it.
How Cliffside helps
If you want this model to stick, treat it like an operating model, not a document. Cliffside can help you implement the gates with templates, training, and assurance that keeps risk explicit as the business moves.
If you have any questions about anything related to this article, or if you’d like to have detailed discussion with our specialists, feel free to get in touch. Contact us online or call our team on (02) 8916 6389!