Japan faced an unprecedented cyberattack.
Every one of you knows that while the attacker is automated, the defender is not. The fastest eCrime breakout time, i.e., the interval between initial access and the first lateral move, was 27 seconds, and one intrusion exfiltrated data four minutes after initial access (CrowdStrike 2026 Global Threat Report). Attacks by AI-enabled adversaries rose 89% year over year.
Set that against the enterprise clock. A microsegmentation policy change moves through a CAB in weeks. An exception is granted verbally and remembered by one person. A supplier’s access is reviewed annually. Identities are assigned to AI agents and they remain unmonitored. When containment must happen in under 29 minutes, and it takes 29 days to establish the authority to contain, the architecture has already conceded.
Watch: See the same AI-assisted attack in two environments and how ColorTokens blocks its access paths.
Over the past few months, I have spoken with Boards, CISOs, and GRC professionals about the challenges of preparing for the next cyberattack. Many things were common, and one factor stood out among those who took on the challenge of shifting their cybersecurity investment mindset from prevention to survivability.
How do we communicate the tone at the top to the people who deal with information daily?
Yes, I am talking about the structural changes required to address this challenge and rally the whole organization to prepare for the next unprecedented cyberattack. We need a new policy structure.
A policy is the only enterprise artifact that binds a board decision to an engineer’s configuration, survives the people who wrote it, and produces evidence an auditor and a regulator will accept.
If you have read my previous blog, you will recognize the change coming and the change every enterprise must undertake.
Policies for the Breach-Ready Organization
An organization is breach ready when it has decided, in advance and in writing, how much of itself it is willing to lose and has engineered the rest to remain unaffected. Governance can only begin with a policy that drives the engineering of a breach readiness architecture, coupled with organizational support. Everything else is recovery planning by another name.
Two decisions carry that discipline.
- The Maximum Acceptable Material Impact, or MAMI, is the board’s quantified threshold of disruption the enterprise can absorb and remain a viable market entity, stated in money, regulatory exposure, and customer trust.
- The Minimum Viable Digital Enterprise, or MVDE, is the architected set of business capabilities, processes, and digital assets that must keep running inside that threshold. At the same time, an attacker is active three microsegments away.
While MAMI is a governance decision, MVDE is an architecture. Neither survives contact with a digital enterprise unless policies carry it and are reviewed and updated as the organization’s digital context changes. In the age of AI, policies must be reviewed and updated as the context changes.
Six High-Level Policies and Two Mandatory Clauses in Each Actually Do the Trick
Why six?
ISO/IEC 27002 names twelve topic-specific policies. NIST SP 800–53 has twenty family policy controls. The CSA CCM has a policy control in nearly every one of seventeen domains. Taken literally, an enterprise would maintain between twelve and thirty policy documents. Most that try end with a library nobody reads, overlapping obligations that contradict each other, and an annual review cycle that consumes the governance function entirely.
Six is the smallest number that covers every obligation mentioned above while keeping each document ownable by one accountable executive and readable in a sitting. The consolidation is deliberate: fewer documents, each with a single owner, each with a clear reason to exist, and none of them a dumping ground.
Now let us look at the policy structure. In almost every organization, policy structures form pyramids, with the Information Security Policy at the top. The pyramid matters as much as its contents.
A control that cannot be traced upward to a stated intent is an orphan; under budget pressure, organizations cut orphan controls first, and under attack, they miss them first. A stated intent with no policy beneath it is a slogan. An organization cannot write these six policies during an incident, and the window to do so calmly is closing.
Policy 1 sets the intent; every other policy inherits it.
Policy 1 — Information Security Policy
Purpose. To state the board’s intent for enterprise-wide information security, declare the Maximum Acceptable Material Impact, commit the organization to a Minimum Viable Digital Enterprise that survives the next breach, and establish the authority under which the other five policies are issued.
Owner: The board, through the CEO. Approver: Anyone authorized by the board. Custodian of the document: The CISO. Review: Annually, and on any material change to the business, any major incident, any change in MAMI, and any relevant change in laws and regulations.
This is the shortest of the six and the hardest to write. It should not run beyond 2 pages. Everything in it is a decision; nothing in it is a control.
Policy 2 — Acceptable Use of the Digital Environment
Purpose. To define what every user of the digital environment, internal or external, human or non-human, may and may not do. To make those rules verifiable through checklists and system-specific guidelines. To bind users to them through undertakings, and to state the consequences of violation.
Owner: Chief Information Security Officer, jointly with Human Resources for the human population and with the CIO for the non-human population. Approver: Executive committee. Review: Annually, on significant change, and whenever a new class of user or agent is introduced.
Of particular concern today is agentic AI. This policy must state that no identity may exist in the digital environment without a named human custodian, a declared purpose, an entitlement scope, and an expiration date. Therefore, a named human owner must sign the acceptable use undertaking only after having understood the implications and penalties of non-conformance.
Policy 3 — Breach Readiness
Purpose. To establish the capability that keeps the enterprise within MAMI while an attacker is active inside it. To establish cyber-defense models for anticipation; breach-ready zoning and microsegmentation that bounds the blast radius; the assessment that proves the bound holds; the incident and crisis machinery that runs when tested; the reporting that satisfies every applicable clock; and the playbooks that tell each population what to do.
Owner: Chief Information Security Officer. Approver: Executive committee, with the board’s risk committee noting. Review: Annually, after every major incident, after every exercise, and when MAMI or MVDE scope changes.
This is the largest of the six and the one that distinguishes a breach-ready organization from a compliant one. It is also the policy most often found in fragments: a segmentation standard here, an incident response plan there, a crisis manual in another function, with no single governance. This policy clarifies crisis management, cybersecurity incident and breach response, and helps build the playbooks required during breaches. This policy also governs activities performed by other teams, such as networking, IT infrastructure, backup, and storage. The policy must include a complete reporting matrix before any incident, because no organization can assemble it quickly after a breach.
Policy 4 — Digital System Custodianship
Purpose. To ensure that every digital system in the enterprise has one identified, competent, accountable human custodian with defined responsibilities and real authority — and that this custodian can never be a non-human.
Owner: Chief Information Officer, with the CISO. Approver: Executive committee. Review: annually, and whenever the system estate changes materially.
This policy must describe what an owner must be able to do, what they must know, or what happens when the role is vacant. The policy must govern all aspects of IT Service Management that can lead to cybersecurity gaps during service-quality failures. Each failure is invisible until an incident, at which point the question of who can authorize isolating this system has no answer within 29 minutes.
Access the CISO’s Guide to Containment: How EDR-integrated microsegmentation helps CISOs establish containment before attackers move laterally.
Policy 5 — Cybersecurity Operations
Purpose. To govern every operational cybersecurity capability, such as identity, access, authorization, network security, data security, cryptography, logging and monitoring, and secure development, and to bind them to the IT service management disciplines that determine whether they hold: change, configuration, asset, vulnerability, and patch management.
Owner: Chief Information Security Officer, with the CIO for the ITSM disciplines. Approver: Executive committee. Review: Annually, and when the technology estate changes significantly.
Most enterprises govern these separately, and the seam between them is where breaches happen. An unmanaged change reopens a segmentation boundary. An incomplete asset inventory means a vulnerability scan that covers 90% of the estate and reports 100% coverage. A patch SLA that nobody measures against a configuration baseline that nobody maintains produces an audit pass and a compromise in the same quarter. The MVDE makes the coupling of ITSM and the SOC unavoidable.
Policy 6 — Data and AI Governance
Purpose. To define what the enterprise is protecting and why: how data is classified, owned, located, retained, and disposed of; what privacy obligations attach to it; and how AI and agentic systems that consume, produce, and act on that data are governed across their lifecycle.
Owner: Chief Data Officer or equivalent, jointly with the Data Protection Officer and the CISO. Approver: Executive committee. Review: Annually, upon any change in applicable privacy law, and whenever the organization adopts a new class of AI system.
IBM’s 2026 data shows that more than 20% of organizations reported breaches involving their AI models or applications, and the leading causes were compromised APIs, applications, or plug-ins and cloud misconfiguration. These are conventional failures reaching an unconventional data surface. The corrective is not a separate AI policy bolted alongside a data policy. It is one policy whose classification scheme extends to AI artifacts and whose AI section inherits the classification.
Access the AI Threat Resilience Guide: A practical guide based on the Cloud Security Alliance’s 11 prioritized actions for AI-speed attacks.
The Tone at the Top Must Express Leadership Intent to Operate During Breaches
Policy 1 is the apex because the board approves it directly and it is the only one that expresses what is unacceptable. Policies 2 to 6 are peers beneath it, each inheriting its intent and each answering a different question. The pyramid is not a hierarchy of importance — an unapproved exception in Policy 5 will breach MAMI just as surely as a missing clause in Policy 1. It is a hierarchy of derivation. Every obligation in 2 through 6 must be traceable to a statement in 1, and every statement in 1 must be operationalized by at least one of 2 through 6.
Five Design Rules
1. Tone at the top is a clause, not a sentiment. “Management is committed to information security” is unenforceable and unauditable. A tone-at-the-top clause states a decision with a number attached: the MAMI threshold, the percentage of the enterprise that must remain unaffected, the authority to disconnect, the consequence of non-compliance. ISO Clause 5.2 and CSF GV.RR-01 are satisfied by decisions, not by adjectives.
2. Single-source obligations. Each obligation appears in exactly one policy and is referenced from the others. Patch timelines live in Policy 5, not also in Policy 3; supplier access rules live in Policy 2, not also in Policy 5. Duplicated obligations diverge at the first amendment, and an audit or incident reveals the divergence.
3. No orphan controls, no orphan intents. Run the trace in both directions at every review. A control with no policy above it is unfunded and unowned; a policy statement with no control beneath it is a claim the organization cannot evidence. I would recommend creating a crosswalk to make this trace mechanical rather than a matter of opinion. It is essential to ensure that configurations in every cybersecurity system are aligned to a policy through the correct hierarchy.
4. Machine-readability where the clock demands it. If breakout time is 29 minutes, a policy that relies on a human reading it will not enforce it. Microsegmentation allow-lists, identity entitlements, and configuration baselines must be expressible as policy-as-code with the written policy as its authority. NIST SP 800–207’s Policy Engine consumes exactly this. Write those clauses so they can be compiled: enumerate them, be unambiguous, and avoid “as appropriate.”
5. Policy is not the only instrument. Conflating the four document types is the most common structural defect in an enterprise policy library.
A policy that names a product, a version, or a port number is a standard wearing a policy’s cover, and it will be amended at the pace of technology through a governance process designed for annual change. Keep the volatile content one level down, referenced by name from the policy.
Two Clauses in All Six
Each of the six policies includes two mandatory sections, in addition to its own content.
- Every policy must define how to approve a deviation as a tracked exception, with a named approver, a compensating control, an expiration date, and a route back to the digital system owner.
- Every policy must also name the documentation that makes it operational and auditable—the registers, records, and attestations that let a third party verify the policy ran, not just that it existed.
The authority (typically the incident commander and a named deputy, available 24×7), what it extends to (network isolation, credential revocation, service degradation, third-party disconnection), what it does not extend to (safety-critical shutdown in OT contexts, which needs its own named authority), and the protection afforded to a person who exercises it correctly on incomplete information. Without the last part, nobody will use it twice.
Call to Action
If you are a CISO/CIO/CDO/CAIO reading this, customize your policies and take them to your board.
If you are a Board member looking to help the Board take charge of how AI and digital innovation will drive the company’s future, demand this structure from leadership.
If you are the CEO, prescribe this structure and build it into your governance.
Please prioritize breach readiness. The next AI-powered cyberattack is just around the corner.
To discuss how policy-driven governance can strengthen your organization’s breach readiness, contact our team.
