# Kode-1 > Kode-1 is a digital technology advisory firm for the modern enterprise — partner-led across strategy, systems, delivery, and resilience. Head office: Level 2, 161 Collins St, Melbourne VIC 3000, Australia; also 68 Circular Road, #02-01, Singapore. ABN 42 653 469 544. Contact: partner@kode-1.com · https://www.kode-1.com/contact ## What we do (pillars) ### Strategy & Architecture https://www.kode-1.com/what-we-do/strategy-architecture Set direction. Technology strategy that shapes the next horizon: business ambition translated into target architectures, investment cases, and operating models. Most boards do not lack ideas about where technology should go. They lack confidence in the path between today's reality and tomorrow's ambition. The decisions in that path (what to modernise, what to retire, what to build, what to buy, what to outsource, what to bring in-house) are the decisions Kode-1 is built to help with. Our partners have sat in the chair making these calls. We bring that operator experience to executive teams who need a partner who has been on the other side of the table. ### Systems & Platforms https://www.kode-1.com/what-we-do/systems-platforms Build the systems that run the modern enterprise: platform engineering across cloud, data, integration, and modernised applications, resilient-by-design from day one. The hardest engineering problems in the modern enterprise are the combination of technical complexity, regulatory obligation, organisational politics, vendor sprawl, and legacy decisions made by people no longer in the building. Kode-1 builds in that environment. Our engineering capability is partner-led, meaning every squad has senior people with operator experience embedded in it, and resilient by design, meaning cyber, privacy, and compliance are engineered into the platform from day one. ### Delivery & Adoption https://www.kode-1.com/what-we-do/delivery-adoption Land outcomes, then keep improving them. Program leadership, change and adoption, value realisation, and ongoing optimisation. Most transformations fail in the connective tissue between strategy and technology: adoption, delivery, value realisation. The Optimise pillar exists to operate in that connective tissue: lead programs to landing, close the adoption gap, and keep the platform paying back long after go-live. ### Risk, Resilience & Assurance https://www.kode-1.com/what-we-do/risk-resilience-assurance A practice principle rather than a fourth pillar: operational resilience, cyber, privacy, regulatory, and AI governance designed into every engagement, and available standalone. A discipline that runs through every engagement, every pillar, from day one. Cyber and privacy designed into architecture. Regulatory fluency shaping engineering choices. AI governance designed into AI delivery before models hit production. Independent assurance available standalone when the board needs a second-line review. ## Services ### Advisory Services https://www.kode-1.com/services/advisory Every technology engagement should start with structured discovery, and most don't. Ours, which we call Navigator, puts it first. The whole assessment exists to answer one question with evidence: based on what we find, what should you do next, and what is it worth? The stages run in a fixed order, so discovery comes before design and the decision before the build. We choose technology at Select, the fifth stage, and cost every option before it is chosen. You leave with a recommendation and the pathway it routes to, delivered by Kode-1 or by a specialist partner where that is the better fit. The recommendation stays independent either way. What we do: Independent discovery, run before any purchase, that defines what the engagement should be; One question answered with evidence: what should you do next, and what is it worth?; Technology choice made at Select, never at Discover; Every option costed for value, cost and effort before it is chosen; A recommendation that routes to a pathway, through Kode-1 or a specialist partner - [Navigator Start](https://www.kode-1.com/navigator/start): A fixed-scope discovery sprint: leadership goals and today's estate turned into a clear first move and a 90-day action plan. Independent, fixed fee, in weeks. - [Navigator Grow](https://www.kode-1.com/navigator/grow): A structured assessment across strategy, operating model, technology and risk: a costed roadmap and a preferred direction before you commit to a platform. - [Navigator Transform](https://www.kode-1.com/navigator/transform): An enterprise-wide assessment that builds the evidence base for major change: scenario-modelled options, a prioritised portfolio and a multi-year roadmap. ### Deployment Services https://www.kode-1.com/services/deployment Delivering a project on time is the easier half. The harder half is delivering it governed, adopted by the people who have to use it, and with the long-term operation designed in. Our deployment work starts where a decision ends: scope, dependencies and constraints confirmed; integration, data and change requirements understood in detail; a delivery plan with releases sequenced by value and dependency. A structured method carries the governance, controls and reporting, and the team adapts delivery inside it as obstacles appear. Change runs as a workstream from day one rather than as a training email the week before go-live. Kode-1 delivers the work, or a specialist partner does under Kode-1's governance, and it ends in a production handover the operating team can run, ours or yours. What we do: Delivery planning and mobilisation before build; Build, configuration and integration in governed increments; Data migration and integration to the existing estate; Governance, controls and reporting fixed from the start; Change and adoption as a workstream from day one; Production handover and documentation ### Managed Services https://www.kode-1.com/services/managed Go-live is where the part of a technology investment that has to work every day begins. Our managed services carry that operational load across the estate: cloud and infrastructure, data and AI platforms, applications and identity, and security operations, run by people who understand your environment because they helped shape it. Everything is monitored and managed continuously, tuned each cycle, governed through forums your leadership attends, and improved rather than left as it was handed over. Engage us fully managed, co-managed alongside your own team, or as the operating partner after a deployment we led together. What we do: Cloud and infrastructure operations: monitored, patched, optimised and kept within cost; Data and AI platform operations: pipelines, models and governance run as a discipline; Application and integration support: patches, upgrades and interfaces kept current; Managed identity and access: provisioning, lifecycle and governance operated for you; Security operations centre: monitoring, triage and escalation with clear ownership; Managed detection and response: threats found, contained and shut down; Attack surface and vulnerability management: visibility across an estate that keeps changing; Service desk and end-user support: one queue, tracked to resolution, with the reporting to see what keeps recurring ## Capabilities ### Data https://www.kode-1.com/capabilities/data Most organisations are swimming in data, or drowning in it. Not all data is created equal, and unlocking its value hinges on awareness and control: knowing what you hold, where it lives, who can reach it, and whether it can be trusted. Kode-1 builds that control end to end: governance programs with real operating models, discovery and classification across structured and unstructured estates, access remediated to least privilege, and lineage mapped from ingress to egress. Those are the foundations that make analytics, AI, and reporting trustworthy. What we do: Data and AI strategy: the target estate and operating model; Data governance advisory and enablement: program, framework, and policies with accountability designed in; Data discovery and classification: structured and unstructured, labelled and protected; Data risk and access assessment: exposure found, least privilege enforced; Data loss prevention and lifecycle management: protected from ingress to egress; Data inventories and lineage mapping: ingress to egress, regulator-ready; Data platform and analytics engineering: trustworthy foundations for BI and AI ### AI https://www.kode-1.com/capabilities/ai AI is now a board-level technology decision, with real regulatory and governance weight and a widening gap between ambition and outcome. Many firms can run a pilot; fewer can take AI from a funded strategy through engineering, adoption, and governance with the same senior people accountable throughout. That end-to-end arc (think, build, optimise, with resilience and governance designed in) is where Kode-1 works. What we do: AI strategy: where AI earns its place and what to fund; MLOps and AI engineering: the platform that runs it in production; AI adoption and value capture: models turned into outcomes; AI security and assurance: model scanning, risk assessment, detection and response; AI governance: ISO 42001 and the NIST AI RMF designed in from the start ### Cyber https://www.kode-1.com/capabilities/cyber Cyber at Kode-1 is the resilient-by-design discipline that runs through every pillar, and a capability you can engage on its own. We cover the full arc from advisory to implementation to operation: strategy and risk quantification, security engineered into the platform, identity and access under governance, security operations that detect and respond, and independent assurance the board can trust, all designed for the standard that holds up under regulatory scrutiny. Anticipate, withstand, evolve. What we do: Cyber strategy and roadmap: risk assessments, quantification, and board-ready priorities; Security engineering: resilience designed into the platform; Risk, governance, and controls: the RRA accelerators across anticipate, withstand, evolve; Identity and access management: governance, privileged access, and identity threat detection; Security operations: detection and response, threat intelligence, incident response, and forensics; Third-party and human risk: supply-chain resilience and behaviour change; Independent and managed assurance: a second line the board can trust; Regulatory fluency: APRA CPS 234/230, SOCI/CIRMP, ISO 42001, Essential Eight ### Infrastructure https://www.kode-1.com/capabilities/infrastructure This is the technology-infrastructure capability (cloud, platforms, integration, and the engineering discipline that keeps them running), distinct from our Critical Infrastructure industry practice. Most enterprises carry a generation of platform debt and a cloud estate that grew faster than its governance. Kode-1 engineers the foundations that modern platforms, data, and AI depend on: cloud landing zones built for regulated workloads, applications modernised without breaking the business, and the DevOps/SRE discipline that keeps it resilient. What we do: Cloud and platform strategy: the target foundation; Cloud platform engineering: landing zones for regulated workloads; Application modernisation: legacy retired without breaking the business; Integration and APIs: the connective tissue of the enterprise; Application and API security: engineered into the platform and the pipeline ## Industries ### Financial Services https://www.kode-1.com/industries/financial-services Banks, insurers, and superannuation funds operate under the most prescriptive technology-regulation regime in the country. CPS 234 (Information Security), CPS 230 (Operational Risk Management) and the Australian Privacy Principles shape every modernisation decision, and the cost of getting it wrong is no longer hypothetical. Kode-1 partners with APRA-regulated institutions on the work that compliance teams cannot do alone: cloud landing zones engineered for resilience, data platforms that satisfy lineage and access requirements, identity programs that survive an audit, and modernisation roadmaps that turn obligation into capability. ### Critical Infrastructure https://www.kode-1.com/industries/critical-infrastructure Energy, water, transport, healthcare, and other critical-infrastructure operators face the most consequential cyber and resilience requirements in Australia. SOCI Act and the Critical Infrastructure Risk Management Program (CIRMP) require an integrated, board-defensible posture across cyber, physical, supply-chain, and personnel risk, and operators of these sectors have little tolerance for failed transformations. Kode-1 works with critical-infrastructure operators on the technology work that the regulator's expectations now demand: secure-by-design platforms, AI governance aligned to ISO 42001 and NIST AI RMF, modernisation roadmaps that maintain operational continuity, and assurance engagements that hold up to second-line review. ### Healthcare https://www.kode-1.com/industries/healthcare Health data is the most sensitive an organisation holds and the least forgiving when it fails. Providers are modernising clinical and administrative platforms while privacy expectations tighten, the health sector is drawn under the SOCI Act, and AI arrives in clinical and operational workflows. Kode-1 partners with health services on the work that clinical and compliance teams cannot do alone: resilient platforms, defensible privacy, and governed AI. ### Insurance https://www.kode-1.com/industries/insurance Insurance runs on models, claims, and trust, and each is now a technology decision. Insurers modernise core platforms and adopt AI in pricing and claims while operating under APRA's information-security and operational-risk standards. Kode-1 partners with insurers to modernise the core without breaking the actuarial and regulatory disciplines the business depends on. ### Government https://www.kode-1.com/industries/government Government technology carries a double burden: citizen expectations set by the best consumer digital experiences, and an accountability, procurement, and security regime (the PSPF, the ISM and Essential Eight, IRAP, data sovereignty) that consumer companies never face. Underneath both sits a legacy estate that has outlived several ministers. Kode-1 works with agencies to modernise without breaking the services people depend on: citizen-facing platforms engineered to the standard the ISM expects, sovereign cloud foundations, and AI adopted with the governance public trust demands, designed in from day one. ### Mining https://www.kode-1.com/industries/mining Mining runs on operational technology, and the OT/IT boundary is where the sector's hardest technology problems now live: autonomous fleets, remote operations centres, and telemetry-driven decisions on one side; enterprise platforms, cyber obligations, and mandatory climate-related financial disclosure under AASB S2 on the other. Convergence is not optional, but done carelessly it imports IT's risks into environments where downtime is measured in tonnes and safety is non-negotiable. Kode-1 engineers the platforms where the pit meets the boardroom: OT-aware security aligned to IEC 62443, data foundations for fleet and orebody telemetry, integration from site systems to ERP, and the trustworthy data pipelines that climate disclosure now demands. ## Case studies (real engagements, anonymised) ### From data-risk findings to action in twelve weeks. https://www.kode-1.com/case-studies/data-risk-assessment-remediation Client: A global agribusiness company The challenge: The company knew its data risks in outline but not in the specifics that let anyone act: sensitive information (personal, financial, intellectual property, and regulated data) spread across a large estate, exposure and oversharing unquantified, and retention practices leaving redundant data accumulating risk. Four priorities were clear (classify the sensitive, identify the exposure, realign the access, retire the redundant) and the brief was equally clear: findings that turn into action, not another assessment that ends as a report. What we did: A tool-enabled engagement designed to move from assessment to remediation inside twelve weeks. Discovery tooling was deployed against prioritised data sources confirmed at a scoping workshop, with in-scope stores discovered, categorised, classified, and labelled. Exposure and access gaps were assessed across three workstreams (data loss prevention, identity and access, and retention) with policy design settings and action plans built for each. Remediation ran on the live estate from week three, under a light-touch governance rhythm of weekly progress and risk updates. The outcome: The engagement turns the four priorities into delivered work rather than recommendations: a categorised and classified data inventory with labelling guidance, exposure and oversharing identified and remediated as the work runs, access realigned toward least privilege, and redundant data identified for disposal. It closes with a prioritised risk-reduction roadmap, capability-uplift actions, and cost-saving opportunities, leaving the organisation with priorities actioned and a clear path for what comes next. ### From the server room to a private cloud. https://www.kode-1.com/case-studies/on-premises-to-private-cloud-healthcare Client: A national healthcare distribution company The challenge: The company's infrastructure had grown up on premises: servers owned, housed, and maintained by the business, with the refresh cycles, capacity ceilings, and single-site risk that model carries. In a business whose operations the healthcare supply chain depends on, the question was not whether to move, but how to move without interrupting the work: a platform decision that had to serve reliability first and modernisation second. What we did: We assessed the on-premises estate (what ran where, what depended on what, and what genuinely needed to move first) and designed a private-cloud target that fit the company's operational and compliance requirements. The migration was then sequenced workload by workload, with dependencies mapped, cutovers planned around the operating rhythm of the business, and each move verified before the next began, so the estate transitioned without the business standing still. The outcome: The company's infrastructure now runs on a private cloud: the on-premises estate retired, capacity and resilience managed as a service rather than a hardware refresh cycle, and a foundation in place that future modernisation can build on instead of working around. The migration completed with operations running throughout. ### Data governance that leadership could finally see. https://www.kode-1.com/case-studies/data-governance-superannuation Client: A major Australian superannuation and investment company The challenge: One of Australia's largest pension payers faced a widening gap between its data governance and its obligations: a growing set of Australian and US regulatory demands, contractual data and intellectual property that needed stronger protection, and a leadership team yet to be convinced that centralised data governance was worth funding. Governance existed on paper; what was missing was a program the business could see working. What we did: We assessed the existing procedures and the business value chain to define what governance needed to cover, then built the working parts: a comprehensive operating model with tailored policies and standards, hands-on guidance for the teams applying them, and a scalable program design with clear solution options. A cost-effective data-governance technology platform was then implemented to carry the program, meeting evolving compliance and privacy requirements without adding operational drag. The outcome: The company now runs a data governance program designed to grow with the business: critical contractual data and IP under strengthened protection, obligations met by mechanisms rather than documents, and, the piece that had been missing, a governance model whose value leadership can see and stand behind. The practices were established without the cost blowout the organisation had feared. ### A cyber strategy the whole business could execute. https://www.kode-1.com/case-studies/cyber-strategy-roadmap-resources Client: An ASX-listed resources company The challenge: A globally operating, ASX-listed resources company needed structure and insight in its cyber risk management: stakeholders across the business held different views of the priorities, the roadmap ahead was unclear, and internal capability needed lifting from within rather than replacing from outside. The goal was a cyber program the organisation could align on and execute with confidence. What we did: We built the cyber strategy and roadmap with the organisation rather than for it: bringing structure to how cyber risk was framed and measured, working across stakeholders to align on a shared view of priorities, and sequencing the roadmap so execution could start immediately and build momentum. Alongside the strategy work, we introduced risk-management practices designed to outlast the engagement, embedded into the company's own governance processes. The outcome: The results exceeded the targets set at the outset. Stakeholders now work from a shared set of priorities, internal capability has been measurably lifted, and the practices introduced during the engagement are embedded in the company's governance processes, running as part of how the business operates, not as an initiative that ended when the engagement did. ### Guardrails that let AI move fast, safely. https://www.kode-1.com/case-studies/ai-security-guardrails-marketplace Client: A leading online marketplace company The challenge: Generative AI initiatives were scaling quickly across the organisation, every department wanted in, but the guardrails had not kept pace: no clear guidance on approved tools and systems, limited internal AI-security depth, and no structured way to see or manage the risks the new systems introduced. The business needed to keep moving at the speed the market expected, with a level of safety and visibility it did not yet have. What we did: We established a full AI security program tailored to the organisation's risks: governance committees with proper controls and guidelines, a process to identify, manage, track, and treat AI risks, and an AI guardrail solution giving generative initiatives a structured, secure path to production. SOC capabilities were assessed for AI threat detection and an AI threat-response program developed. Red-teaming of AI applications surfaced real vulnerabilities, with concrete recommendations to reduce them, and a phased plan now reinforces the program year over year. The outcome: The organisation gained a level of AI safety and visibility it had not had before, and used it to accelerate rather than brake: AI use and functionality increased across the business on top of a governance foundation that made each deployment defensible. Vulnerabilities found in red-teaming were remediated before they became incidents, and secure deployment is now the default path rather than the exception. ### One identity program across many brands. https://www.kode-1.com/case-studies/identity-strategy-multi-brand Client: A diversified ASX-listed services company The challenge: Operating multiple consumer brands across distinct service industries, the company's identity estate had grown brand by brand: password management, privileged access, and identity governance each handled differently in different places, with no single view of the gaps and no agreed path to close them. Thousands of end users and privileged users needed managing as one program rather than many. What we did: We built the identity strategy from an honest gap assessment: where password management, privileged access, and identity governance actually stood across the brands, and what a unified program needed to look like. The output was clarity and a practical roadmap (sequenced, costed, and owned) covering the entire identity program, with our support continuing through the delivery of the changes that mattered most. The outcome: The company transformed how it manages passwords, privileged access, and identity governance: access management now runs one way across thousands of end users and privileged users, the gaps that were invisible brand-by-brand are visible and owned centrally, and the identity program runs to a roadmap the whole organisation understands rather than a collection of local practices. ## Insights ### CPS 230 is not a compliance project https://www.kode-1.com/insights/cps-230-is-not-a-compliance-project · published 2026-07-21 APRA's Prudential Standard CPS 230 has been in force since July 2025, and for many regulated entities the transition period for pre-existing contractual arrangements runs out in mid-2026. Most programs we see are on schedule against their plan. Fewer are on schedule against the standard's actual question, which is not "is your register complete?" but "do your critical operations keep running when something breaks?" That distinction sounds rhetorical. It is not. CPS 230 is written as an outcome standard: identify your critical operations, set tolerance levels for disruption, and be able to demonstrate, to your board first and your supervisor second, that you can stay within them. A program can produce every artefact the standard names, on time, and still leave the organisation unable to answer the outcome question. We call that the compliance-shaped version of resilience: it photographs well and fails under load. The compliance-shaped version has a recognisable anatomy. The critical operations list is assembled by workshop rather than derived from how value actually flows through systems. Tolerance levels are set at whatever the current architecture can plausibly meet, rather than what the business can actually absorb, which quietly inverts the standard's intent. Third-party dependencies are catalogued at the contract layer, while the platform layer, where a single shared integration or an unowned legacy service can take down three "independent" critical operations at once, stays invisible. And business continuity is tested by walkthrough, in business hours, with the people who wrote the plan in the room. The engineering-shaped version starts somewhere else: with the map. Which systems, integrations, data flows, and providers actually sit under each critical operation? Not the architecture diagram from the last program, but the current, honest map, including the parts nobody owns. In our experience this mapping exercise is where CPS 230 earns its money, because it surfaces the concentration risk the org chart hides. When two critical operations quietly share one ageing integration platform, that platform is a critical operation, whatever the register says. With the map in hand, tolerance levels become engineering requirements rather than aspirations. A two-hour tolerance on payments is a statement about failover design, data replication, and the automation of recovery, or it is fiction. This is the test we encourage boards to apply to any tolerance level they are asked to endorse: ask what, specifically, in the architecture makes this number true. If the answer is a plan to write a plan, the number is not yet real. Third-party risk follows the same logic. CPS 230's material service provider requirements are commonly read as a contracting exercise: refresh the agreements, insert the audit and step-in clauses, build the register. Necessary, and insufficient. The operational question is what your architecture does in the hours after a material provider fails. Can you degrade gracefully? Is there a substitution path, and has anyone exercised it? Contractual remedies operate on legal time; your tolerance levels operate on operational time. The gap between the two is an engineering problem, and it is yours, not the provider's. Then there is testing. The standard requires a testing program for business continuity, and the difference between testing that satisfies and testing that strengthens is severity. Scenario walkthroughs have their place, but resilience is demonstrated by exercising the failure paths for real: pulling the dependency in a controlled window, running the failover, timing the recovery, and feeding what broke back into the backlog. Organisations that do this discover their real recovery times are usually multiples of their documented ones, which is precisely the information a board needs before it attests, not after an incident makes it public. None of this argues against the program disciplines: the registers, the policies, the board reporting. They are the floor, and the floor matters. But compliance is a floor. Resilience is the outcome. The organisations that will be comfortable in front of APRA in 2027 are the ones treating CPS 230 as a forcing function to engineer resilience into their platforms (designed in, not bolted on) and using the compliance artefacts to describe something that is actually true. A practical place to start: take your single most critical operation and trace it end to end: systems, integrations, data, providers, people. Set its tolerance level against what the business can genuinely absorb, then have engineers, not report writers, assess whether the architecture makes that number true. The gap you find is your real CPS 230 program. ### Where AI earns its place https://www.kode-1.com/insights/where-ai-earns-its-place · published 2026-07-14 Every board has an AI conversation running, and most have funded something: a pilot, a proof of concept, a partnership announced with some ceremony. The gap between those conversations and the balance sheet has a familiar shape: pilots that impressed, decks that circulated, and a technology strategy that still treats AI as an initiative rather than a capability. The missing artefact is rarely vision. It is rarely use cases either; most organisations are drowning in use-case lists. What is missing is a fundable path: a prioritised view of where AI earns its place in the operating model, what it costs to run properly, and what has to be true (in platform, data, people, and governance) for the value to arrive. "Earns its place" is deliberate framing. AI in the enterprise is not entitled to a place; it competes for one against every other use of capital and attention. A use case earns its place when three tests pass. The decision or process it touches has to matter at scale; automating something trivial produces trivial value at meaningful cost. The data underneath it has to be trustworthy enough to act on, not just to demonstrate with. And the organisation has to be able to absorb the change: a model that the business routes around is an expense, not a capability. Applied honestly, the tests make AI strategy a prioritisation decision first. Strategy means saying no, or at least not yet, to most of the list. Rank what remains by value against feasibility, where feasibility includes the unglamorous variables: the condition of the data, the integration reality, the regulatory exposure of the decision being automated. A short, ranked portfolio that the board actually understands beats a long list that flatters everyone's project. The second commitment is engineering. An AI strategy that does not commit to a platform is a wish. Models that matter run in production, which means deployment pipelines, monitoring, retraining, access control, and cost management: the machinery the pilot never needed. This is where the funding conversation has to be honest: the cost of running AI properly is the cost of the platform and the operating discipline, not the cost of the pilot that produced the demo. The third is governance, and for regulated entities this is now concrete rather than abstract. ISO 42001 gives AI governance a management-system shape an auditor can work with. The NIST AI RMF gives risk teams a shared vocabulary for AI-specific failure modes. And prudential expectations reach AI through the standards that already apply: operational resilience, information security, model accountability. The practical insight is about sequence: governance designed alongside the strategy is a design input, cheap and mostly invisible. Governance retrofitted after deployment is the most expensive kind of control there is; designed in, not bolted on, is a budget position as much as a principle. These three are one decision. A strategy that prioritises without committing to engineering is a deck. Engineering without governance is a liability accumulating interest in a regulated environment. Governance wrapped around use cases that never earned their place is theatre. Made together, they produce something a board can actually fund: a portfolio, a platform sized to it, and a governance design mapped to real standards, with a visible path from the first decision to a governed outcome, and the same senior people accountable across it. A practical place to start: take your current AI use-case list and apply the three tests: does it matter at scale, can the data be trusted, can the organisation absorb it. Expect the list to shrink sharply. That is not the exercise failing; that is the exercise working. The survivors are your AI strategy. ### Your AI is only as good as your data platform https://www.kode-1.com/insights/ai-is-only-as-good-as-your-data-platform · published 2026-07-07 Model quality has a ceiling, and it is not the model. Enterprises that push past the pilot stage discover their genuine constraint quickly: not the algorithm, not the vendor, not the talent: the condition of the data estate underneath. The model is a lens. Pointed at a fragmented estate, it magnifies the fragmentation. The fragmented estate has a recognisable anatomy. Data is spread across systems nobody fully owns. Extracts feed extracts, until the version of a customer in the warehouse and the version in the CRM disagree in ways nobody can adjudicate. Lineage exists in the heads of two engineers who might leave. Access is managed by exception: granted when someone asks loudly enough, rarely revoked, never designed. Every report built on this inherits its fragility. So does every model. AI raises the stakes on all of it. A flawed number in a report has a human in the loop: someone reads it, doubts it, checks it. A model operates at scale and speed, and increasingly sits inside automated decisions where no one is reading each output. The tolerance for quietly wrong data drops precisely as the volume of decisions rises. And when a regulator, an auditor, or a customer asks why the model decided what it decided, the explanation starts with data lineage. If you cannot say where the data came from, what transformed it, and who was allowed to touch it, you cannot defend the output, no matter how good the model is. The prerequisites, then, are not exotic. Lineage: for the data each critical decision consumes, you can trace where it originated and what has been done to it since. Access: who and what may use each dataset is designed and enforced by the platform, not administered by exception. Ownership: every significant data domain has a named owner with the authority to fix it: a person, not a committee. None of this is glamorous. All of it is the difference between analytics you can act on and analytics you can only present. Platform architecture serves these disciplines rather than substituting for them. The modern patterns (lakehouse designs, a governed catalogue, quality monitored at the point of ingestion rather than the point of embarrassment) are the right defaults. But the pattern matters less than the discipline: a governed slice of the estate where lineage is real, access is designed in, and quality is measured, beats a fashionable architecture wrapped around the same old sprawl. The sequencing argument deserves care, because "fix the data first" can become its own failure mode: a multi-year foundation program with no visible value, cancelled at the second budget review. The workable sequence is narrower: take the AI use case that matters most, and build the governed slice it needs: its sources traced, its access designed, its quality measured. Ship both together. Then extend the foundation use case by use case. The estate gets governed incrementally, but deliberately, and every increment pays for itself with a capability the business can see. The remaining work is organisational, and engineering cannot do it alone. Ownership is an operating-model decision: someone has to hold each domain, with the mandate and the budget to keep it healthy. Data quality becomes sustainable when it is a production discipline with an owner, not a cleanup project with an end date. Analytics and AI are only as good as the data beneath them. A practical place to start: take the AI use case you most want to ship and trace its data end to end: sources, transformations, access, owners. Score what you find honestly against lineage, access, and ownership. The gap is not a reason to stop. It is your data platform backlog, in priority order. ### FinOps when the regulator is watching https://www.kode-1.com/insights/finops-when-the-regulator-is-watching · published 2026-06-30 The cloud cost conversation arrives in every enterprise, usually about eighteen months after the migration was declared a success. In a regulated enterprise it arrives with a complication the standard FinOps playbook does not address: some of your most expensive architecture exists because a regulator expects it to. Redundancy across zones and regions. Disaster recovery environments that sit idle by design. Data residency requirements that rule out the cheapest options. Retention obligations that keep storage growing on schedule. The monitoring, logging, and encryption overhead that operational resilience and information security standards effectively mandate. These are not inefficiencies; they are the cost of the obligations the organisation carries. Together they put a floor under cloud spend, and cost-cutting that breaches the floor converts a budget problem into a compliance problem. Often silently: the DR environment that was quietly downsized to hit a savings target fails no test until the day it is needed, or the day a supervisor asks for evidence it works. The floor is real. It is also, in most estates, well below current spend, because most estates carry substantial cost that has nothing to do with any obligation. Instances sized by guesswork and never revisited. Environments that outlived the project that created them. Storage that has never met a lifecycle policy. Non-production platforms running nights and weekends for no one. The discipline that matters in a regulated environment is not cutting; it is classification: knowing, line by line, which dollars are the obligation floor, which are driving value, and which are waste. Classification changes the conversation with the board. A single large cloud number invites a single blunt response. Unit economics (cost per transaction, per customer, per workload, trended over time and attributed to the platforms that generate it) invites better questions. The regulated twist is to attribute the resilience premium explicitly: when the board can see what portion of platform cost is carrying the obligations it has attested to, cost-of-obligation and cost-of-waste stop being the same line item, and the organisation stops accidentally treating one as the other. Making the discipline stick is an engineering problem, not a reporting one. Tagging enforced when resources are provisioned, not reconstructed at month end. Budgets and anomaly alerts wired into the platform, so drift is caught in days. Architecture standards that include cost in the definition of done, so efficiency is designed in rather than audited in. A monthly spreadsheet ritual produces commentary; guardrails in the platform produce behaviour. The same logic makes optimisation continuous rather than annual. Rightsizing informed by real usage telemetry. Commitment purchasing managed against an actual demand forecast. Storage lifecycle policies that run themselves. This is run-and-improve work: the platform keeps paying back when it is tuned, governed, and continuously improved, and cost is one of the dimensions being tuned. The annual cost crusade, by contrast, reliably produces the two failure modes worth naming: the freeze-everything mandate that stalls delivery to save a quarter's optics, and the cut that lands on resilience capacity because idle-by-design looked like waste to someone reading a report. Ownership matters as much as tooling. Cost discipline handed to procurement becomes a contract negotiation; handed to finance alone, it becomes a report. It works when it lives with the platform team, the people who can actually change the architecture, in partnership with finance, with the obligations owner in the room whenever the floor is in question. That is a small operating-model decision with outsized returns. A practical place to start: take your highest-spend platform and classify its bill into three buckets: the obligation floor, the spend that drives value, and the waste. The third bucket funds the FinOps practice several times over. The first bucket becomes a board conversation worth having: what resilience actually costs to carry. That is a number worth knowing precisely, ideally before the regulator asks how you know your obligations are funded. ### What an AI interaction costs https://www.kode-1.com/insights/what-an-ai-interaction-costs · published 2026-07-24 The AI line item has reached board level, and it usually arrives as one number: what we are spending. That number provokes exactly one conversation: is it too much? And it answers nothing. A total cannot be governed. It cannot tell you which use cases are earning their keep, whether the economics are improving, or what happens to the bill if adoption doubles. The unit that can be governed is the cost of an interaction: everything consumed to produce one governed outcome. For a customer-service assistant, one resolved enquiry. For a document pipeline, one processed document. For a decision-support model, one decision informed. Attribute the spend to the unit and the conversation changes from "is the bill too big?" to "is this interaction worth what it costs?" That is a question a board can actually answer. Most unit-cost calculations flatter the answer, because they count inference alone. An honest number includes the whole chain: the model calls, including the retries and the guardrail checks; the retrieval and orchestration around them; the share of the evaluation harness that keeps quality measurable; the monitoring that keeps it observable; and the human review time that sits inside the loop for anything that matters. On real workloads the flattering number and the honest number can differ by multiples, and decisions made on the flattering number are decisions made on fiction. For a regulated enterprise there is a further discipline, and it mirrors cloud cost management: attribute the governance premium explicitly. Evaluation, monitoring, human review, and audit-trail capture are the cost of operating AI under obligations; the same way redundancy and DR are the cost of operating platforms under them. When the board can see cost-of-control and cost-of-capability as separate lines, two things follow. The governance spend stops being invisible overhead vulnerable to quiet cutting. And a use case whose economics only work without the governance is exposed for what it is: a use case whose economics do not work. The number matters most as a trend. Unit cost falling as volume grows and prompts, models, and retrieval are tuned is the signature of a healthy use case. Unit cost flat or rising while volume grows is a signal to re-examine the design, or the use case. And the trend only means anything against the other side of the ledger: the value of the interaction. Cost per resolved enquiry is interesting; cost per resolved enquiry against the cost of resolving it the old way is a business case. Getting to the number is an engineering exercise, not a finance project. The platform already knows most of it: token counts, call logs, retry rates, evaluation runs. What is usually missing is attribution, tagging each call with the use case it serves, and an owner who publishes the number monthly. Teams that treat unit cost as a platform metric, visible on the same dashboard as latency and error rate, get the discipline almost free. Teams that treat it as a quarterly analysis exercise get a stale estimate and an argument. This is what unit economics buys: kill-or-scale decisions grounded in evidence, business cases that survive finance review, and vendor conversations conducted in the unit the business actually consumes. It also changes the model conversation: when a smaller, cheaper model clears the evaluation bar for a use case, the unit economics say so immediately, and when it does not, the premium for the larger model is a recorded decision rather than a default. A practical place to start: pick one production use case and instrument it end to end: every model call, every retry, the evaluation share, the human minutes. Produce one honest number and its trend. Take it to the next board conversation instead of the total. ### Agentic AI, without the hype https://www.kode-1.com/insights/agentic-ai-without-the-hype · published 2026-07-17 Agentic AI is currently the loudest conversation in enterprise technology, which is precisely when a board needs the quiet version. Start by separating what actually changes from what does not. What changes is this: an agent acts. A model that drafts an answer for a human to use is a capability. A model that executes (updates the record, sends the message, moves the work to the next system) is an operational actor. It holds credentials. It has access. It produces side effects. Its failure mode is not a wrong answer in front of a sceptical human; it is a wrong action inside a system, at machine speed, possibly many times before anyone looks. That is a different risk profile, and it deserves the treatment any operational actor gets, not the treatment a chat window gets. Where do agents earn their place today? In work that is bounded, evaluable, and reversible. Triage and routing, where the agent's decision is checked by where the work lands. Drafting for review, where a human gate is the design, not a concession. Reconciliation and data hygiene, where correctness is verifiable against a source. Test generation and code review support, where the output is inspected by the pipeline that consumes it. The pattern is consistent: high volume, well-specified, and either checkable or undoable. Where do they not yet earn their place in a regulated enterprise? Open-ended authority over customer outcomes. Anything that moves money without a human gate. Irreversible actions in systems of record. Not because the models cannot sometimes do these things well, but because the failure cost is asymmetric and the evidence base for unsupervised reliability is not there, and a board asked to accept that risk should see evidence, not enthusiasm. The honest posture is a horizon, not a verdict: the boundary moves as evaluation methods and track records mature, but it moves on evidence. There is an engineering consequence too: agents concentrate the case for platform discipline. Sandboxed execution, scoped credentials issued per task, action logs a human can actually read, and kill switches that work at the speed the agent does; these are platform features, not use-case features. Building them once, underneath every agent, is the difference between an agent program and a collection of experiments. It is also where the data foundation shows: an agent acting on data nobody governs automates the consequences of that fact. The governance surface for agents is concrete, and existing frameworks already hold it. Approval boundaries: what an agent may do alone, what it may only propose. Permissions engineering: least privilege applies to an agent exactly as it applies to a service account: scoped access, rotated credentials, revocation that works. Decision records: what the agent did, on what input, under which version. Evaluation before authority and monitoring after it. ISO 42001 and the NIST AI RMF give this a management-system shape and a risk vocabulary; agents make the controls concrete rather than abstract. The strategy test is the same one every AI use case faces (does it matter at scale, can the data be trusted, can the organisation absorb the change) with a fourth test agents add: is the action reversible, or gated until the evidence says it can be trusted alone? A practical place to start: pick one bounded workflow and run an agent with a human approval gate. Measure quality, cost, and how often the human overrides. Log every override with its reason, because the reasons are the design feedback. Expand the agent's authority only as the override rate earns it. Authority granted on evidence is a capability; authority granted on excitement is an incident report with a delay on it. ### Why your board still can't see its technology risk https://www.kode-1.com/insights/why-your-board-cant-see-its-technology-risk · published 2026-07-28 Boards have never spent more time on technology. Cyber has a standing agenda item and a regulator behind it. AI has a working group, a policy, and a queue of briefings. And yet ask a director to describe where the organisation's technology risk actually sits, and the answer is usually the last incident or the most recent briefing topic, not the estate the enterprise runs on. The gap is structural, not personal. Cyber and AI reach the boardroom because they arrive pre-packaged: a named threat, a regulatory prompt, a shared vocabulary, and an industry of advisers supplying the briefing. The digital estate (the systems, integrations, and data flows that critical operations stand on) arrives with none of that. It has no single owner below the CIO, no annual report section, no headline when it quietly degrades. So the agenda fills with the topics that come with words, and the risk accumulates in the layer that does not. What the board sees instead are proxies. Project status reports, graded green, amber, red. Compliance registers, audit findings, budget variance. Each is true as far as it goes, and none of them is the estate. A transformation program can be green for six consecutive quarters while landing on a platform that cannot carry what it delivers. A register can be complete while two critical operations quietly share one ageing integration that nobody owns and nothing monitors. The proxies report the work; they do not report the ground the work stands on. Compare the way the same board handles financial risk. There, directors hold shared instruments (the balance sheet, the management accounts, the external audit) and they know how to interrogate them. A director who does not like a number can pull the thread. Technology risk has no equivalent instrument in most boardrooms: there is no artefact a director can hold that connects the operations the board is accountable for to the systems and dependencies they actually run on. Without the instrument, scrutiny defaults to whatever management chooses to present. The consequences are not abstract. Boards attest to operational resilience on tolerance levels they cannot connect to architecture, which means attesting without sight. Transformation investments are approved on the strength of a deck, because the deck is the only view available. And concentration risk (the shared platform, the single provider, the one integration under three critical operations) is discovered the way it is always discovered when nobody maps it: during the incident. Visibility, when it exists, has a specific shape. It is a map, kept current and kept honest, from each critical operation down to the systems, data flows, and providers underneath it. It shows what is shared, what is single point of failure, what is past its supportable life, and who owns each piece. It is not a technology document; it is a governance instrument; the technology equivalent of the balance sheet, and about as optional. A board does not need to become technical to use it. It needs to ask the questions the instrument makes answerable. Which systems sit under our most critical operation, and which of them are shared with other critical operations? What is the oldest thing on that path, and who owns it? Which single failure would we genuinely struggle to survive, and what specifically makes our stated tolerance for it true? If the answers take six weeks to assemble, that latency is itself the finding: the organisation does not currently have sight of its own ground. None of this asks directors to read architecture diagrams. It asks management to build the instrument and the board to insist on it; the same division of labour that already exists for the numbers. Digital leadership at board level does not begin with enthusiasm for technology. It begins with refusing to govern what cannot be seen. A practical place to start: ask management for one page: the top three critical operations, mapped to the systems and providers underneath them, with owners and single points of failure marked. Whatever cannot be produced inside a month is not a reporting gap. It is the current, honest measure of how much of its technology risk the board is carrying unsighted. ### Fragmented systems are a competitive disadvantage your competitors can see https://www.kode-1.com/insights/fragmented-systems-competitive-disadvantage · published 2026-07-31 No organisation chooses fragmentation. It accumulates, one reasonable decision at a time. The acquisition kept its systems because integration would have delayed the deal. The project shipped its own database because the deadline was real. Each vendor era left a platform behind, and each platform found a workload to justify its keep. Every one of those decisions had a business case. The sum of them has none. From the inside, the sum is hard to see because it feels like history rather than a condition. People bridge the seams every day: rekeying data between systems, reconciling versions of the same number in a weekly meeting, keeping the spreadsheet that quietly joins what the platforms cannot. Each workaround is rational, each is small, and the organisation absorbs the cost invisibly because it is dispersed across a hundred job descriptions and no budget line. From the outside, the same seams are sharp. The customer repeats their details to a second team because the first team's system does not talk to it. The quote takes four days because it crosses four systems. The renewal offer arrives after the moment has passed, priced on data that was true last quarter. Service is warm in one channel and cold in another, because each channel sees a different version of the same customer. Customers cannot see architecture, but they feel it, in elapsed time and repeated questions, and they do not grade it on a curve. That is the asymmetry worth taking to a board. An organisation that runs as one digital enterprise (connected platforms, data that agrees with itself, processes that cross systems without human glue) operates at a different clock speed. It launches in weeks where the fragmented competitor schedules quarters. It prices on current data. It sees one customer, whole. None of that is a technology advantage in any interesting sense; it is a decision advantage, and it compounds every quarter it is held. Fragmentation persists because of how it hides from governance. It has no single owner: every system has a custodian, but the seams between them belong to no one. Its cost never appears as a number: it is paid in salary time, elapsed days, and lost offers, none of which reach a business case. And investment decisions are judged one system at a time, where the integration burden is always someone else's line item. Under those rules, consolidation reads as maintenance, and maintenance loses to any initiative with a launch date attached. Meanwhile the tax compounds, because every future initiative pays it. Each new product must be wired into the sprawl. Each regulatory change must be implemented several times, consistently, in systems that disagree about the facts. And the ambition currently on every board agenda pays the tax at the steepest rate: analytics and AI inherit the estate beneath them, and a model pointed at fragmented data does not fix the fragmentation; it operationalises it, at scale, with confidence. The response that works is not the heroic re-platforming program; those consume years and frequently return the same sprawl in newer technology. The response that works treats connectedness as a strategic property to be bought deliberately, seam by seam. Map the estate honestly. Rank the seams by what they cost: the ones customers feel, the ones critical operations cross, the ones every future initiative will have to pay for. Then close them in that order, and hold the line that new initiatives must not mint new ones. A practical place to start: take the customer journey that matters most to revenue and walk it end to end, counting the systems it crosses, the hand-offs between them, and the places a person bridges the gap by hand. Then ask what each seam costs in elapsed time, yours and the customer's. That number has been missing from the board conversation. It belongs in the same paragraph as market share, because over time, it decides it. ### The data question your board should be asking https://www.kode-1.com/insights/the-data-question-your-board-should-be-asking · published 2026-08-03 Every board now asks an AI question. Far fewer ask the question that comes before it. "Are we doing something with AI" is comfortable, and management always has an answer. The harder, prior question is about data: which of our critical decisions run on data we trust, and which only look like they do? The distinction that question surfaces is between the data-driven enterprise and the data-decorated one, and from a board seat they are easy to confuse. The data-decorated organisation has dashboards everywhere. Reports arrive on schedule, beautifully rendered. And underneath, decisions are still made the old way: by anecdote, by seniority, by the weekly meeting whose real function is to reconcile which of three conflicting versions of a number the organisation will agree to believe. The decoration is expensive, and it photographs well, and it changes nothing about how the enterprise actually decides. There is a simple test, and it works at board level: would you act on this number without someone checking it first? Ask it of the numbers behind pricing, risk, capital allocation, customer decisions. Where the honest answer is no, where every important figure travels with a caveat and a person whose job is to verify it, the organisation does not have an analytics capability. It has a reporting habit with manual assurance, and the cost of that assurance is paid on every decision, in money and in days. What makes a number trustworthy is not sophisticated and never has been. Lineage: it is known where the data originated and what transformed it on the way. Ownership: a named person, not a committee, holds each significant data domain, with the authority and budget to fix it. Access: who and what may touch the data is designed and enforced, not accumulated by exception. Boards already understand these disciplines perfectly, because they are the same ones financial control is built on: provenance, accountability, authorisation. No director would accept a set of management accounts assembled the way most operational dashboards are: by extract, from systems that disagree, with no audit trail. The data question asks that the numbers running the business meet the standard already demanded of the numbers reporting it. For a regulated enterprise, the stakes are sharper, because attestations rest on data. Operational resilience tolerances, incident reporting, financial and non-financial disclosure; each is a claim built on numbers, and a claim whose lineage cannot be shown is a hope with a signature on it. Regulators have noticed; the supervisory question is decreasingly "what is the number" and increasingly "show me how you know". And this is also, properly asked, the AI question. Every AI ambition inherits the data estate beneath it. A report built on doubtful data at least passes a sceptical human on its way to a decision; a model operates at scale, inside automated processes, with no one reading each output. The tolerance for quietly wrong data falls precisely as the volume of decisions rises. An organisation that cannot answer the trust question is not one prudent step away from AI value; it is standing on the part of the bridge that is not built. None of this argues for the multi-year data foundation crusade; those programs fail by asking for years of cost before showing a decision improved. What works is narrower: pick the decisions that matter most, and make the data under each of them trustworthy (traced, owned, access-designed) one governed slice at a time, each slice paying for itself in a decision the business can feel. The estate improves incrementally, and deliberately, and visibly. A practical place to start: name the three numbers this board relies on most, and ask management to trace each one end to end, where it originates, what transforms it, who owns it, and what happens when two systems disagree. The gaps that exercise finds are not a reason for alarm. They are the data strategy, in priority order, written by the board's own reliance. ## Playbooks ### The AI governance operating model https://www.kode-1.com/playbooks/ai-governance-operating-model · published 2026-07-22 For: For boards, risk committees, and the CIOs and CISOs who answer to them Most AI governance fails the same way: a policy document exists, a committee exists, and neither can answer the only question that matters: who decided this model could do this thing, and on what evidence? This playbook lays out the working parts of governance that can answer it. 1. What good looks like Good AI governance is boring. Every material decision about an AI system has a named owner. Every policy statement is backed by a control that actually enforces it. The evidence a board or regulator would ask for is produced by the platform as a by-product of operating, not assembled by hand in the week before the meeting. Governance designed alongside the AI strategy is cheap and mostly invisible. Retrofitted, it is the most expensive control there is. 2. Decision rights Write down who may decide what. Who approves a new use case entering development. Who approves it entering production. Who approves a model change, a prompt change, an expansion of what the system is allowed to touch. For material systems, pair the business owner with technical and risk sign-off: two perspectives, named individuals, recorded outcomes. If a decision cannot be traced to a person, it was not governed; it just happened. 3. The policy hierarchy Three layers, each answering a different question. Principles, set by the board: what we will and will not use AI for. Standards, set by the governance forum: what must be true of any system we run (evaluated before deployment, monitored in production, human gate on irreversible actions). Controls, built by engineering: the mechanisms that make the standards true. The hierarchy earns its keep at the bottom: a policy without a control enforcing it is a hope with a letterhead. 4. The operating cadence Governance is a rhythm, not a document. A forum that meets on a schedule; a live register of every AI system and its risk tier; the evidence for each (evaluation results, incidents, drift) visible in the meeting, not requested after it. The forum decides: approve, expand, remediate, retire. The decisions are recorded where the next audit can find them. Frequency scales with risk: material systems monthly, the long tail quarterly. The register itself stays cheap: a page per system: owner, tier, status, last evaluation, open actions. If it takes a project to maintain, it will die; if it takes ten minutes before the forum, it will live. 5. Mapping to the frameworks ISO 42001 gives the management system a certifiable shape; the NIST AI RMF gives risk teams a shared vocabulary for AI-specific failure modes. Use them as the map, not the territory: build the operating model that fits how your organisation actually decides, then map it to the frameworks for the auditor. An operating model built from the framework outward tends to produce paperwork that mirrors the standard and controls that mirror nothing. 6. The first 90 days Inventory what is already running, including what nobody approved. Tier it by risk. Name an owner for every material system. Stand up the register and hold the first forum with whatever evidence exists; the gaps in that meeting are the backlog. Build the two controls that matter most first: access (who and what can invoke the system) and evaluation (proof it does what it claims). Then rehearse: run one attestation dry-run against a production system and time how long the answers take. The test of the whole model is a single question asked without warning: show me the decision that put this system in production. If the answer is a link, you have governance. If the answer is a meeting, you have a project. ### AI evidence and audit readiness https://www.kode-1.com/playbooks/ai-evidence-audit-readiness · published 2026-07-15 For: For risk and compliance leaders, and the platform owners who hold the evidence When scrutiny arrives (auditor, regulator, board, or journalist) the questions about an AI system are predictable. Why did it decide what it decided? Who approved it? What data shaped it? What changed since, and who approved that? How do you know it still works? Organisations rarely fail these questions for lack of governance. They fail them because the evidence was never captured, or was captured somewhere nobody can find under pressure. This playbook is the architecture for capturing it. 1. The questions, written down Start by writing the actual questions your obligations imply, in plain language, for each material system. The prudential lens supplies most of them: operational risk wants to know the system's failure modes and their controls; information security wants to know its access and its data paths; the board wants to know who is accountable. A question you have written down is a question you can rehearse. A question you have not is the one that finds the gap. 2. Evidence at design Every material system gets a decision record at inception: its purpose, the decision it touches, the data it consumes and where that data comes from, the evaluation criteria it must meet before production, and the named approvals. This is one document, produced once, kept current. It is the anchor every later question hangs from, and it is nearly impossible to reconstruct honestly after the fact. 3. Evidence at deploy Version everything that shapes behaviour: model, prompts, retrieval configuration, guardrails. Record the evaluation results that gated the release, and who accepted them. A deployment you cannot reproduce is a deployment you cannot explain; an explanation that starts with "we believe it was configured to…" has already failed. 4. Evidence at run Production evidence accumulates on its own if the platform is built to keep it: monitoring against the evaluation baseline, drift measurements, incidents and their resolutions, and the outcomes of human review, including the overrides, which are the richest signal you hold about where the system's judgement and yours diverge. Retention follows your record-keeping obligations, decided once, applied automatically. Capture is designed once, at the platform layer, so every new system inherits it; evidence per system should get cheaper as the estate grows, not more expensive. 5. Attestation posture AI reaches most boards through the standards that already exist (operational risk and resilience, information security, privacy) not through a parallel AI regime. Architect the evidence to serve those attestations. When the operational-resilience attestation comes due, the AI systems inside critical operations should appear in it with the same rigour as any other system: mapped, evidenced, tested. An AI evidence base that cannot feed the existing attestation calendar is a second filing cabinet, not a capability. 6. The dry run Rehearse before it counts. Pick one production system, convene the people who would face a real review, and ask the written questions cold. Time how long each answer takes and note where the answer is a person's memory rather than a record. An answer that takes three weeks to assemble is a finding; you have chosen to discover it privately. The gaps become the backlog, in priority order. Repeat the rehearsal twice a year: the second one is where the improvement shows, and the habit is the capability. 7. The first 90 days Write the questions for your two most material systems. Create their design decision records, backfilled honestly. Turn on deploy-time versioning and gate-keeping for one of them end to end. Schedule the first dry run for day 60, and let what it surfaces set the next quarter's work. Evidence produced as a by-product of operating always beats evidence assembled the week before the audit, in cost, in credibility, and in what it does to the organisation's nerves when the request lands. ### Leading AI-fluent teams https://www.kode-1.com/playbooks/leading-ai-fluent-teams · published 2026-07-08 For: For executives and delivery leaders building AI capability into real work Every organisation is somewhere on the AI adoption curve, and most are stuck in one of four recognisable failure modes. Naming yours is the first step; this playbook covers the four, and the leadership work that gets a team past them. 1. The four failure modes Prohibition: AI is banned or so restricted it might as well be. The work does not stop; it goes underground, onto personal accounts and personal devices, where none of your controls apply. Prohibition does not reduce AI risk; it removes your visibility of it. Free-for-all: everyone uses everything, nobody reviews anything. Quality becomes uneven in ways that surface months later, and sensitive data quietly flows into tools nobody assessed. The energy is real; so is the liability. Tokenism: there is a pilot, a demo day, and a slide for the board, and no change to how real work is done. Tokenism is the most comfortable failure mode because it photographs like progress. Tool-worship: licences are bought, victory is declared, and the hard work, redesigning the work itself, is skipped. Adoption metrics look healthy. Output quality tells the truth. 2. Fluency is a property of work, not people Training courses produce familiarity; redesigned work produces fluency. Pick the workflows where assistance is expected, build the AI step into the way the work is actually done, and make review of AI-assisted output an explicit skill: taught, practised, and valued. The team that learns to review well learns faster than the team that learns to prompt well, because review is where judgement compounds. 3. Policy that enables Good policy is short and legible: what is allowed by default, what needs a gate, what is prohibited and why. Then the part most policies miss: a fast path to ask. If the answer to "can I use this for that?" takes three weeks, people stop asking, and you are back to the underground. Make the safe way the easy way: sanctioned tools that are genuinely good, defaults that protect data without ceremony. 4. Measure honestly Usage is not fluency. Licences active and prompts sent measure enthusiasm, not capability. Measure what the work shows: the quality of reviewed output, cycle time on the redesigned workflows, escalation and rework rates, and whether the review step is catching what it should. If assisted work is faster but rework is up, you have measured the truth early, which is the point. Publish the measures to the teams doing the work, not just upward: people improve what they can see, and hiding the scoreboard from the players helps nobody. 5. Leaders go first Teams calibrate on what leaders do, not what they announce. A leadership team that visibly uses the tools, visibly reviews the output, and visibly talks about what worked and what did not gives the organisation permission to do the same, including permission to report honestly when the tool made something worse. 6. The first 90 days Find out where AI is already touching your work, including the unsanctioned uses; that map is your real baseline. Choose two workflows that matter and redesign them with assistance and review built in. Publish the short policy with its fast path. Teach review before you teach prompting. Keep the first measures small and repeatable, so the second cycle can compare against the first. Report the honest measures to your own leadership, especially the unflattering ones; the fastest way to license honesty below you is to practise it above. The goal is not an organisation that uses AI. It is an organisation whose judgement about AI compounds, workflow by workflow, review by review, until fluency is how the work is done. ### The data governance operating model https://www.kode-1.com/playbooks/data-governance-operating-model · published 2026-07-01 For: For chief data officers, CIOs, and the risk leaders who co-own the estate Data governance has a reputation problem: in most organisations it means a council that meets quarterly, a policy nobody has read since it was approved, and an estate that behaves exactly as it did before either existed. This playbook lays out the version that works: the one where governance is a property of how data is operated, not a committee that observes it. 1. What good looks like Every significant data domain has a named owner with the authority and budget to keep it healthy. Every dataset that matters carries a classification that systems can act on. When someone asks where a number came from, the answer is lineage, not archaeology. And the obligations (the Privacy Act and its APPs, CPS 234's expectations on information assets, the retention rules of your sector) are met by the way the platform works, not by an annual scramble. 2. Ownership before tooling The first failure mode of data governance is buying a catalogue before naming the owners. A tool can record who should care about a dataset; it cannot make anyone care. Name an owner for each domain (a person, not a committee) and give them three things: the mandate to fix what is broken, the budget to do it, and a definition of healthy they are measured against. Ownership is the control every other control depends on. 3. Classification that survives contact with reality Keep the tiers few enough to remember: public, internal, sensitive, and whatever your regulator adds. Then make classification the platform's job wherever possible: applied at creation, inherited through pipelines, checked at the point of use. A classification scheme that relies on every employee labelling every document correctly is a scheme that has already failed; one that relies on defaults, automation, and spot-checking has a chance. 4. Lineage and quality as operating disciplines Lineage answers where the data came from and what has touched it; quality answers whether it can be trusted at the point of use. Both decay the moment they become projects instead of properties. Build them into the pipeline: transformations recorded as they run, quality measured at ingestion against thresholds the owner set, breaches routed to the owner as incidents rather than discovered in a report review months later. 5. The cadence A register of the domains and their health. A forum that meets on a rhythm, chaired by someone with authority, deciding real things: accept this risk, fund that remediation, retire this feed. Decisions recorded where the next person can find them. The same discipline as any governance that works, and the same test: if the forum has not stopped or changed anything in two quarters, it is a briefing, not governance. 6. The obligations map Map each obligation to the mechanism that satisfies it. The APPs' collection and use limits map to classification and access controls. CPS 234's information-asset expectations map to the register and its criticality tiers. Retention and deletion obligations map to lifecycle policies that actually execute. When the regulator asks how an obligation is met, the answer should name a mechanism, not a policy. 7. The first 90 days Pick the three domains that matter most to the business and name their owners in the first fortnight. Stand up the register with honest health ratings: red is information, not failure. Get classification running automatically on one high-volume pathway. Hold the first forum in month two with real decisions on the agenda. By day 90, one domain should be measurably healthier, and the organisation should know who owns the other two. Data governance succeeds when it is boring: owners known, tiers applied, lineage recorded, forum deciding. The alternative is exciting, usually in the week a regulator, an AI program, or a breach asks questions the estate cannot answer. ### Finding and securing sensitive data https://www.kode-1.com/playbooks/finding-and-securing-sensitive-data · published 2026-06-24 For: For CISOs, security architects, and the platform owners who hold the keys Every organisation believes it knows where its sensitive data lives. Almost none do. The customer records are in the CRM, and in the export someone took for a migration in 2019, the spreadsheet finance keeps for reconciliation, the test environment that was refreshed from production, and the collaboration site nobody has opened since the project ended. Security architecture built on the official map protects the official copies. This playbook is about the rest. 1. The posture discipline Sensitive-data security is a loop, not a project: discover what exists, classify what it is, right-size who can reach it, watch how it is used, and feed what you learn back into the loop. Run once, it produces a report that is stale in a quarter. Run continuously, it produces posture: the state the APPs assume when they speak of reasonable steps, and CPS 234 assumes when it asks how information assets are protected commensurate with their criticality. 2. Discovery, honestly Start where the copies breed: file shares, collaboration platforms, object storage, mailboxes, and the analytics estate. Discovery that only scans the systems of record confirms what you already knew; discovery that scans where people actually work finds the unmanaged copies, and the point is the unmanaged copies. Expect the first pass to be uncomfortable. That discomfort is the finding. 3. Classification at scale Manual labelling does not scale to the volumes discovery surfaces, so let patterns and context do the first pass (identifiers, document shapes, source systems) and spend human judgement only where the automation is unsure. Precision matters more than coverage at the start: a small set of correctly-identified crown jewels beats a large set of maybes, because everything downstream (access, monitoring, response) keys off the classification being right. 4. Access right-sizing Over-permissioning is not an accident; it is the default state of any estate more than a few years old. Access accretes: projects end, roles change, nothing is revoked. Treat least privilege as an ongoing process with an owner: entitlement reviews driven by actual usage (who has access they never use), broad-groups-by-default replaced with scoped grants, and every sensitive dataset carrying an owner who answers one question on a cadence: who can reach this, and why? 5. Watching use, not just storage A dataset at rest with correct permissions can still be misused by an authorised account. Monitor the patterns that matter: unusual volumes, unusual destinations, access outside the shape of someone's role, dormant accounts waking up. The Essential Eight hardens the paths in; use-monitoring watches what happens after, and it is also where insider risk becomes visible while it is still small. 6. The AI multiplier Every copilot and model deployment turns your access debt into an exposure engine: these tools surface whatever the requesting account can reach, at conversational speed, with none of the friction that used to make over-permissioning survivable. Before connecting an assistant to the estate, run the loop hard on whatever it will index. The question is no longer only who can open this file; it is what can retrieve it, and repeat it, on that person's behalf. 7. The first 90 days Run discovery on the three environments where copies breed fastest. Classify the top tier only: the data whose loss triggers the NDB scheme or a prudential conversation. Right-size access on the ten worst findings; they will not be subtle. Stand up use-monitoring on the crown jewels. And schedule the second discovery pass before the first one is forgotten; the loop, not the report, is the deliverable. The uncomfortable truth of sensitive-data security is that the perimeter never failed; the copies did. Find them first, or someone else does. ### Data breach readiness https://www.kode-1.com/playbooks/data-breach-readiness · published 2026-06-17 For: For executives, CISOs, and privacy officers who will own the first 72 hours When a breach lands, two clocks start. The first is the attacker's: how far the compromise spreads while you work out what happened. The second is the regulator's: under the Notifiable Data Breaches scheme, a suspected eligible breach must be assessed within thirty days, and notified to the OAIC and affected individuals as soon as practicable once it qualifies. Neither clock pauses while you locate the asset register, argue about who decides, or discover that the person who understood the logging left last year. Readiness is everything you do before the clocks start. 1. What the assessment clock assumes you already know To assess a breach quickly you must already be able to answer: what data was in the affected system, whose data it is, how sensitive it is, who and what could access it, and what the logs can prove about what actually happened. Every one of those answers is a readiness artefact: the data inventory, the classification, the access map, the logging coverage. An organisation that cannot answer them in days has not got a response problem; it has a posture problem wearing a response problem's clothes. 2. The runbook Write the sequence before you need it. Contain: isolate what is compromised without destroying the evidence. Assess: scope the data, the subjects, and the harm; the NDB test is whether serious harm is likely, and that judgement needs facts, not adrenaline. Notify: the OAIC statement, the affected individuals, and the sector obligations that stack on top; an APRA-regulated entity has material-incident notification duties on a much shorter fuse than thirty days. Name the decision-makers for each step, and their deputies, because breaches respect neither calendars nor leave. 3. Evidence, prepared cold The breach report writes itself if the platform was built to remember: what was accessed, from where, when, under which identity. It cannot be reconstructed if the logs were never kept, rotated away after a week, or scattered across systems nobody can correlate under pressure. Decide log coverage and retention for the crown-jewel systems as a readiness investment; the cost is modest, and the alternative is standing in front of a regulator saying we believe rather than we know. 4. Communications, drafted in peacetime The worst time to write a customer notification is the day you must send one. Draft the skeletons now: the OAIC statement, the customer notice in plain language, the executive brief, the media holding line. Legal reviews them once, calmly, in advance. On the day, you fill in facts instead of arguing about sentences, and the notice that reaches customers is clear about what happened and what they should do, which is the difference between a breach handled and a breach compounded. 5. The rehearsal A runbook that has never been run is a theory. Twice a year, take a plausible scenario (the compromised account with broad access, the misdirected extract, the third party that lost your data) and play the first 72 hours for real: the actual people, the actual tools, the actual draft notifications. Time the steps. The gaps you find (the number nobody had, the log that did not exist, the decision nobody would own) are the readiness backlog, discovered privately at rehearsal prices instead of publicly at incident ones. 6. The first 90 days Confirm the crown-jewel inventory and its access map: the assessment clock's first questions. Fix logging on the two systems where the evidence would currently be thinnest. Write the runbook and the communication skeletons. Then book the first rehearsal for day 60 and let its findings set the next quarter. None of this is exotic; all of it is the difference between thirty days that feel survivable and thirty days that feel like freefall. Breaches are not fully preventable. Being unprepared for one is. ### Cyber awareness that changes behaviour https://www.kode-1.com/playbooks/cyber-awareness-that-changes-behaviour · published 2026-06-10 For: For CISOs, executives, and the leaders who set the security culture Most security awareness programs can prove exactly one thing: that people clicked through the training. Completion sits at some high and reassuring number, the annual phishing simulation produces its annual chart, and the incidents keep arriving through the same human doorways they always have. The problem is not that awareness does not matter; the human layer sits inside most incident chains. The problem is that completion measures compliance, and compliance was never the risk. 1. Measure behaviour, not attendance The unit of awareness is not the course completed; it is the behaviour under pressure. Does the unexpected invoice get paid or queried? Does the odd login prompt get entered or reported? Does the urgent request from the CEO's address get actioned or verified? These are observable events (simulation results, reporting rates, response times, real-incident entry points) and together they describe the organisation's actual human risk far better than any completion dashboard. Measure those, trend them, and let them drive the program. 2. Segment by risk, not by headcount Awareness delivered identically to everyone is awareness calibrated for no one. Finance approvers face invoice fraud; engineers with production access face credential theft; executive assistants face impersonation; new starters face everything at once. Map the roles that attackers actually target (the money-movers, the access-holders, the identity-adjacent) and weight the effort there. The annual all-staff module can stay as the floor; the program lives in the targeted work above it. 3. Intervene at the moment, not the anniversary Behaviour changes closest to the decision. A short, specific nudge when someone is about to do the risky thing (or immediately after a near-miss, while the memory is real) outweighs an hour of generic content on the anniversary of last year's hour. Build the loop small and frequent: simulations that reflect current attacker behaviour, feedback that teaches rather than shames, and content that arrives because a signal suggested it was needed, not because the calendar did. 4. Make reporting the win condition The single most valuable human security behaviour is reporting early: the suspicious email, the clicked link, the credential entered in a moment of autopilot. Every program choice either encourages that or suppresses it. If clicking a simulation triggers public embarrassment or remedial punishment, people learn to hide, and the organisation loses its early-warning system precisely where it needs it most. Celebrate the report, time-stamp the response, and treat a rising report rate as the success metric it is; a reported click is a contained incident; a hidden one is an investigation. 5. Culture is set above, evidenced below Teams calibrate on what leaders do. An executive who verifies an unusual payment request out loud, reports their own near-miss, and accepts security friction without theatre does more for the human layer than any campaign. This is also where obligations meet behaviour: CPS 234 and the Essential Eight assume controls operate as designed, and humans operate the controls. A board that asks for behavioural risk measures, not completion rates, signals what the organisation should optimise for. 6. The first 90 days Baseline honestly: current reporting rate, simulation outcomes by role, and where real incidents entered. Identify the five highest-risk role groups and design their targeted interventions first. Reset the reporting experience so the fastest reporters are visibly valued. Retire the metrics that measure activity, and stand up the two that measure risk: behaviour under test, and time-to-report. Then run the loop and let the trend, not the calendar, set the cadence. An awareness program succeeds when the phrase changes: from everyone completed the training to the organisation reports faster than the attacker moves. One is a certificate. The other is a control. ### Securing identity end to end https://www.kode-1.com/playbooks/securing-identity-end-to-end · published 2026-06-03 For: For CISOs, identity leaders, and the platform owners who hold the directories The modern breach rarely opens with an exploit. It opens with a login (a phished password, a reused credential, a service account nobody remembered) and from that point the attacker is not breaking anything. They are using the systems exactly as designed, as someone the systems trust. Which means identity is not one control among many; it is the terrain the whole defence stands on. This playbook is about holding it end to end. 1. The coverage gap Most organisations have MFA. Almost none have it everywhere, and everywhere is the standard, because attackers do not queue at the protected front door. The gaps are predictable: legacy applications and protocols that cannot speak modern authentication, administrative interfaces reached from inside the network, command-line and machine access paths that never met a prompt. Map real authentication traffic against MFA enforcement and treat every uncovered path as what it is: the door that will be used. The Essential Eight puts MFA near the top for a reason; the maturity levels are a coverage question, not a purchase question. 2. The identities that are not people For every human identity, a mature estate carries several that are not: service accounts, application identities, integration credentials, scheduled jobs. They are the worst-governed population in most directories: unowned, unrotated, over-privileged, and invisible until one is compromised. Inventory them, name a human owner for each, scope them to least privilege, and rotate or vault their secrets. Then hold the line as AI agents join the population: an agent with credentials is a non-human identity with initiative, and it inherits every discipline on this list before it inherits any access. 3. Cutting off lateral movement The first credential an attacker lands on is rarely the one they want. The campaign is sideways: from workstation to server, from user to admin, on legitimate credentials that raise no alarm. The counters are structural. Tier the estate so administrative credentials never touch the machines where ordinary work, and ordinary phishing, happens. Scope admin rights to the task and the hour, not the person and the year. And make privileged paths the most heavily authenticated journeys in the organisation, because they are the destination the whole attack is walking towards. 4. Watching identity in use Prevention leaks; watching catches what leaks. Identity misuse has a shape: logins at machine speed, from new places, in impossible sequences; service accounts doing interactive things they have never done; dormant identities waking. The directory and the authentication logs already record most of it. The work is turning that record into questions someone actually asks: which identities behaved out of character this week, and who checked? 5. The obligations frame None of this is optional posture. CPS 234 expects controls commensurate with the criticality of the information assets identities can reach; the Essential Eight makes MFA and privileged-access restriction explicit; and every breach-readiness plan in the building assumes the access map is known. Identity work is the rare investment that shows up in every one of those conversations at once, and the first one a serious incident review will ask about. 6. The first 90 days Map authentication coverage honestly and list the uncovered paths; that list is the program. Inventory the non-human population and name owners for the twenty most privileged. Break the flattest lateral path with tiering or scoped admin. Stand up one identity-misuse question on a weekly cadence. And when the first AI agent requests credentials, treat the request as the test of everything above: scoped, owned, watched, or not issued. The perimeter did not disappear. It moved into the directory, and it logs in. ### Bringing your APIs under management https://www.kode-1.com/playbooks/bringing-apis-under-management · published 2026-05-27 For: For platform owners, integration leads, and the architects who own the seams Every integration decision of the past decade left an API behind, and most enterprises are now connected by a tissue of interfaces nobody can fully list. The official ones live in a portal. The rest (the point-to-point endpoint a project stood up in a hurry, the internal service that three other teams quietly took a dependency on, the version that was deprecated but never switched off) carry production traffic with no owner, no contract, and no place in anyone's risk register. This playbook is about bringing the estate under management before it decides to prove the point. 1. Find the estate, not the portal Start with traffic, not documentation. Gateway logs, load balancers, and network observability will surface the APIs that actually carry calls, including the shadow interfaces nobody registered and the zombie versions that should have died at deprecation. Expect the discovered list to be multiples of the documented one. Each discovery gets the same triage: who owns it, who consumes it, what data it moves, and whether it deserves to exist. 2. The gateway as control point An API policy enforced in a document is a suggestion; enforced in the traffic path, it is a control. Route the estate through a gateway layer and the disciplines stop depending on every team's goodwill: authentication and authorisation applied per consumer, rate limits that protect shared platforms from their own clients, observability that shows who called what and what it cost, and versioning rules enforced where the calls flow. The goal is not a bigger portal. It is a single place where the organisation's interface rules are true by construction. 3. Lifecycle as a contract An API is a promise to its consumers, and promises need lifecycle discipline. Version deliberately. Publish deprecation with dates and consumer notifications, and honour the dates; a deprecation nobody enforces trains consumers to ignore the next one. Retire what the traffic says is dead. The catalogue that results is not documentation for its own sake; it is the dependency map every incident, migration, and modernisation plan will reach for first. 4. Security at machine scale API consumers are machines, and machine trust deserves the same discipline as the identity estate: credentials scoped to the least each consumer needs, rotated and revocable; no shared keys passed between teams like folklore; data classification flowing through to the interface, so an endpoint serving sensitive data is authenticated, rate-limited, and logged like one. Most large data losses are, mechanically, API calls, made by a caller who was allowed to make them far too broadly. 5. The AI traffic has already arrived Model calls, retrieval requests, and agent actions are API traffic, usually the fastest-growing and least-governed kind in the building. Routing it through the same control point buys the same disciplines exactly where they are newly needed: per-consumer authentication for agents, rate and budget limits that keep experimentation from becoming an invoice, and the call-level logging that AI evidence and unit-economics work both depend on. The organisations that already manage their APIs will govern their AI traffic with machinery they own; the ones that do not will meet both problems at once. 6. The first 90 days Run discovery from traffic and triage the surprises: ownership first. Route the three most sensitive or most-consumed APIs through the gateway with authentication and rate limits enforced. Publish the catalogue with owners and lifecycle status, and schedule the first honest deprecation. Then point the AI traffic at the same front door before its volume makes the decision for you. Integration debt is quiet until it is not. The estate under management is the one that can change safely, and changing safely is the whole game. ### Securing AI systems https://www.kode-1.com/playbooks/securing-ai-systems · published 2026-05-20 For: For CISOs, AI platform owners, and the security teams inheriting the model estate Security teams have spent two years watching AI arrive faster than it can be assessed. Developers embed models into products, business units adopt copilots, and somewhere in the estate a downloaded model file is running with nobody able to say where it came from. AI systems are software, and most software security disciplines still apply, but they also fail in ways software never did, and the new failure modes are the ones nobody's runbook covers. This playbook maps the surface and the disciplines that hold it. 1. Find the AI you already have Every AI security program starts with an inventory it does not expect. Models embedded in vendor products, copilots adopted team by team, notebooks calling external APIs with company data, fine-tuned weights sitting in object storage. Discover before defending: what models run where, what data each can reach, what each can do, and who owns it. The unowned entries are the finding; an AI system without an owner is an incident with a start date nobody wrote down. 2. The model supply chain A downloaded model is third-party code that arrives as opaque weights; it cannot be read, only tested. Treat the model supply chain with the discipline the software supply chain took a decade to learn: known provenance for every model and dataset, integrity checks before anything runs, dependency scanning for the frameworks around it, and a registry of what is approved. A model pulled from a public hub into production without validation is an unaudited executable with a marketing page. 3. Injection and leakage Generative systems have a property classical software never had: their instructions and their input share a channel. Anything the model reads (a document, a web page, a customer message) can attempt to become an instruction, and anything in the model's context can attempt to leave. The defences are layered, not singular: separate and mark untrusted input, constrain what the system can disclose and do regardless of instruction, filter both directions of the channel, and test the whole assembly adversarially, because the attacker will, and this class of attack is written in plain language, not shellcode. 4. Contain the agents An agent extends the injection problem with hands. A poisoned input to an agent is not just a wrong answer risk; it is an action risk: the email sent, the record changed, the tool invoked. Containment is architectural: least-privilege credentials scoped per task, approval gates on irreversible actions, sandboxed execution, and kill switches that operate at the agent's speed. The identity and API disciplines already in this series are the substrate; an agent program that skipped them has no floor to stand on. 5. Watch it run, plan for the day AI systems drift, degrade, and get probed, often quietly. Monitor behaviour against the evaluation baseline, watch for the patterns of probing and extraction, and log at the level the incident will need: what went in, what came out, under which version, on whose behalf. Then extend the incident-response plan to AI specifically: how a compromised or manipulated model is contained, rolled back, and investigated. The teams that rehearse a poisoned-model scenario once will handle the real one; the teams meeting the concept mid-incident will improvise. 6. The first 90 days Run AI discovery and publish the honest inventory, owners attached. Put provenance and integrity checks in front of the next model deployment. Adversarially test the most exposed generative system, the customer-facing one, and fix what falls out. Scope the first agent's credentials as if it were a new administrator, because functionally it is. And add the AI scenario to the next incident rehearsal, before the calendar decides for you. AI security is not a new discipline so much as every existing discipline, applied to software that reads its instructions off the wire. The organisations treating it that way are unremarkable in the best possible sense. ### Building security into software delivery https://www.kode-1.com/playbooks/building-security-into-software-delivery · published 2026-05-13 For: For engineering leaders, CISOs, and the platform teams who own the pipeline Every vulnerability that reaches production was cheaper to fix at some earlier point, and cheapest of all at the keyboard where it was written. That arithmetic is the whole case for building security into software delivery rather than inspecting it in afterwards, and it has just been sharpened by a new fact: an increasing share of the code was not written at a keyboard at all. This playbook covers the pipeline disciplines, and what changes when the author is a model. 1. Scan where the work happens Four kinds of defect want catching before merge, not after deployment. The code itself: the injection flaw, the broken access check. The dependencies: the open-source components that are most of every modern application, each carrying its own history. The secrets: credentials committed in a hurry, which become identity incidents the moment the repository is wider than intended. And the infrastructure definitions: the misconfigured bucket or over-permissive role, now expressed as code and therefore checkable as code. Wire all four into the pipeline so every change is examined on the way in, automatically, every time. 2. Prioritise by risk, not by count Turn every scanner on and the first result is a number in the thousands, and a security queue nobody will ever clear. The program lives or dies on triage: which findings are in code that actually runs, reachable from an input an attacker controls, on an asset that matters? A short list ranked by exploitability gets fixed; a long list ranked by severity label gets a dashboard. Measure the program by risk retired (critical findings fixed, time-to-fix trending down) never by findings produced, which rewards noise. 3. Keep developers in flow Security that interrupts gets bypassed; security that fits the workflow compounds. Findings surface in the tools engineers already inhabit (the editor, the pull request) with the fix suggested where possible, not filed as a ticket to a queue in another team's system. The pull request is the natural gate: block on the few classes that must never merge, advise on the rest, and keep the feedback fast enough that waiting for it never becomes the reason to work around it. Every workaround is a policy failure, not a people failure. 4. AI writes code faster than review reads it Assisted development multiplies output, of good code and of plausible-looking vulnerable code alike, delivered with a confidence that invites rubber-stamping. The response is not prohibition; it is holding the gates. Generated code enters through the same pull request, meets the same scanners, and gets the same review, with reviewers taught the specific failure modes of generated code: invented dependencies, subtly wrong authorisation logic, patterns copied from a training corpus that never saw your threat model. The pipeline that already treats every change with suspicion barely notices the new author. That is the point of having one. 5. The obligations dividend A pipeline that scans, gates, and records does the compliance work as a by-product: the evidence of secure development practice that CPS 234 implies and every security questionnaire asks for is the pipeline's own log. Assurance by extraction, screenshots and attestations assembled annually, costs more and proves less than a delivery system that enforces the standard on every merge. 6. The first 90 days Turn on dependency and secrets scanning first: highest signal, least noise. Add code and infrastructure scanning gated on new findings only, so the legacy backlog does not bury the program on day one. Publish the triage rule and the two metrics that matter: critical time-to-fix, and gate-bypass count, which should be zero. Then sample the AI-assisted changes merged last quarter and review them cold; the result sets the training agenda, and occasionally the incident response one. The delivery pipeline is where the organisation's intentions about security become enforceable. Everything upstream is culture; everything downstream is response. The pipeline is where it is cheap. ### Seeing the network you actually run https://www.kode-1.com/playbooks/seeing-the-network-you-run · published 2026-05-06 For: For CISOs, network and platform leaders, and the teams who own detection Ask a security team what enters and leaves the network and most can answer; the perimeter has been watched for decades. Ask what moved sideways last Tuesday (server to server, workload to workload, inside the cloud estate) and the answer gets quieter. Yet sideways is where the campaign happens: the perimeter is crossed once, and everything after travels east-west, frequently encrypted, often in environments where nobody inspects a single packet. This playbook is about seeing the network you actually run, not the one on the diagram. 1. Map the blind spots honestly Inventory where traffic flows against where visibility exists. The usual gaps repeat everywhere: traffic between workloads inside the same cloud network, container-to-container paths, the links between on-premises and cloud that carry the most sensitive replication, and anything wrapped in TLS, which is now nearly everything. Score each blind spot by what an attacker could do there unobserved. That scored map is the program; without it, visibility spend follows vendor categories instead of risk. 2. The wire as ground truth Logs describe what systems say happened; the network records what actually moved. The distinction matters most on a bad day: an attacker with sufficient access edits logs and silences agents, but the traffic still crossed the wire. Network-derived telemetry (flows, metadata, and where warranted full packets) is the evidence source that does not depend on the compromised host's honesty. Detection built only on endpoint and log data stands on ground the adversary can reach; adding the network view puts one leg on ground they cannot. 3. Encrypted does not mean invisible Encryption everywhere is the right default and a real inspection problem, but not an absolute one. Metadata alone betrays a great deal: who talked to whom, when, how much, how often, and none of it needs decryption. Where deeper inspection is justified (the crown-jewel segments, the regulated data paths) decrypt deliberately: scoped to defined segments, governed by written policy on what is inspected and what never is, with the privacy obligations engineered in rather than discovered later. A blanket answer in either direction is a policy failure; the discipline is choosing where. 4. Verification is what makes zero trust true Zero-trust architectures assert that no flow is trusted by default, and an assertion without observation is a diagram. The segmentation that looks complete in policy is routinely porous in practice: the forgotten rule, the flat subnet that predates the program, the path that grew during an incident and never closed. Continuous visibility is how the architecture is verified: the difference between believing the segments hold and watching them hold. 5. Feed the tools, and the evidence Raw traffic is too much for every tool to swallow, which is how visibility programs drown in their own success. Filter and route deliberately: each detection and observability tool receives the slice it needs, duplicates removed, irrelevant flows excluded. The same pipeline yields the compliance dividend, when CPS 234 asks how incidents are detected, or a SOCI obligation asks how the operational network is monitored, the answer is a telemetry architecture, not a diagram and a hope. 6. The first 90 days Build the blind-spot map and score it. Instrument the single riskiest east-west segment, usually inside the cloud estate where lateral movement is cheapest. Write the decryption policy before deploying any decryption. Verify one zero-trust boundary with observation rather than configuration review. And route the new telemetry into the incident and breach-readiness evidence base, where the next investigation will be very glad to find it. The network is the one witness present at every stage of an attack. Most estates have never taken its statement. ## Campaigns ### Cybersecurity Awareness Month, without the box-ticking. https://www.kode-1.com/campaigns/cybersecurity-awareness-month · published 2026-08-12 October comes around every year, and most awareness programs reach for the same posters and the same quiz. This year the threat has changed: AI has made social engineering cheaper, faster and far more convincing, and it has put a capable assistant on every desk. We have curated a ready-to-run pack that helps your people pause, look inward, and build habits that hold up under pressure. Why this October is different: Deepfaked voices on the phone. Lures written fluently in your house style. Payment redirections that reference real projects and real colleagues. AI has not invented new cons; it has industrialised the old ones, and the volume and polish now exceed what a once-a-year compliance module prepares anyone for. At the same time your people have been handed assistants of their own, which quietly raises a second question nobody covered in last year's training: what is safe to paste into one, and what is not. The organisations that hold up treat awareness as behaviour change: small habits, rehearsed often, owned by every team. Awareness is a loop, not an event: A module people click through in October is forgotten by November. What survives contact with a real lure is a rehearsed habit: noticing the pressure, checking through a second channel, reporting quickly without fear of looking foolish, and seeing that report acknowledged so the next one comes faster. Everything in this pack is built to run that loop in fifteen-minute pieces, inside teams, in the flow of work. · The loop each asset in the pack is designed to turn, once a week rather than once a year. What is in the pack: Twelve pieces, curated by Kode-1 and ready to run. Add your branding, tailor the examples, and go. · Incident walk-throughs · Which response was right? A short scenario a team can run in fifteen minutes and argue about properly. · Leadership briefing · An exclusive for the executive: what has changed, what it means for the organisation, and what leaders are asked to model. · Industry attack snapshots · The same attack, played out in different sectors, so the threat lands as concrete rather than generic. · Quarterly breach snapshot · A digestible read on what has actually been happening, for the people who never open the security newsletter. · AI guide and behaviour cards · Sixteen one-page cards on working safely with AI: approved tools, enterprise accounts, least-privilege connections, reviewing agent actions, keeping sensitive content out of chat history. · Role-based education cards · Tailored for executives, finance, human resources, IT and remote workers, because the lure aimed at payroll is not the one aimed at an engineer. · Interactive tools · A phishing signal drill, a quishing generator for QR-code lures, and a secure behaviour self-assessment teams can score themselves against. · Posters and stickers · Physical reminders that keep the habit in view long after the session ends: not today phishing, panic is the payload, real ones verify. · A month you can run yourself · No licence, no platform, no consultant on site. Everything is designed to be adapted for internal use and reused beyond October. A four-week plan that fits around real work: One theme a week, fifteen minutes a team. This is how we would run it; the pack works in any order you like. · Week one: make it concrete · Open with the industry snapshot for your sector and one incident walk-through. The goal is recognition, not fear: this is what it looks like here. · Week two: make it personal · Hand out the role-based cards and run the self-assessment. People engage with the lure aimed at their own job in a way they never do with a generic module. · Week three: take on AI · Work through the AI guide and pick three behaviour cards to adopt as team norms. Approved tools, enterprise accounts, and nothing sensitive in chat history is a strong opening three. · Week four: rehearse and reinforce · Run the phishing and QR drills, brief leadership with the executive piece, and put the posters and stickers up. Close by telling people what reporting actually triggers, so the loop keeps turning in November. What this pack will not do: It will not make you compliant, and it does not pretend to be a training platform. It is a month of well-made material that gets people talking about the right things, and a foundation for the habits that matter. If what you need is a governed program with measurement, adoption tracking and evidence for an auditor, that is a conversation rather than a download, and we are happy to have it. Why we put it together: We spend our working lives inside other people's estates, and the pattern is consistent: the control that fails is rarely the technical one. It is the moment someone is rushed, and the lure is good, and there is no rehearsed habit to fall back on. Curating this pack is cheaper for everyone than watching that moment play out. Take it, run it, and if it raises questions about what your people can reach or what your assistants can see, ask us. That is the part we do for a living. ### You cannot secure the data you cannot see. https://www.kode-1.com/campaigns/data-risk-assessment · published 2026-09-18 A Data Risk Assessment is a paid, one-time evaluation of your data estate. In four to six weeks it discovers what sensitive information you hold, classifies it, scores the risk around it, and hands your leadership an evidenced picture of exposure with a roadmap to act on. The question nobody can answer quickly: Ask a technology leader where the organisation's sensitive data lives and who can open it, and the honest answer is usually an estimate. Not through negligence: data spreads faster than the controls around it. A store is created for a project and outlives it. Access is granted for a role and outlives the person. A folder is opened to the whole company to unblock a deadline on a Friday and nobody closes it on Monday. Multiply that by a decade and the gap between who can reach sensitive data and who should is real, unmeasured, and invisible until something forces the question. The estate you have, rather than the one on the diagram: Architecture diagrams show systems. Risk lives in the spaces between them: the export somebody saved to a personal drive, the shared mailbox nobody owns, the site that was opened to everyone for one meeting. An assessment maps the estate as it actually is, then marks the places where sensitive content sits behind access that was never designed. · Every store holds something. The circled ones are reachable by far more people than anyone intended. What usually forces the question: Most assessments start with one of these. If two of them are true, the answer is already overdue. · An assistant rollout is scheduled · Copilot and its peers inherit each person's permissions. Anything an employee can open, the assistant can find and summarise in seconds. · A regulator or an auditor asked · Privacy and AI obligations all begin with the same question about sensitive data, and an estimate is not an answer you can file. · An insurer or a client is asking · Cyber renewals and enterprise procurement now ask what you hold, where it sits, and who can reach it, in writing. · A peer was breached · The board's question after somebody else's incident is always the same: could that happen here, and how would we know? · A merger, divestment or migration · Moving an estate is the moment its contents matter most, and the moment nobody has an inventory to hand. · The storage bill keeps growing · Duplicate and expired data carries cost as well as risk, and no policy has ever deleted a file on its own. What the assessment covers: Discovery and classification · A scan of up to ten terabytes across the sources you choose · Cloud and on-premises, structured and unstructured alike · Classification that reads the content in context, with no rulebook of patterns to maintain · Priority categories agreed up front: personal, payment, health and intellectual property · Risk and exposure · Risk scored on permissions, sharing, location and activity · Files open to far more people than intended · Accounts that should no longer have access to anything · Duplicate and stale records carrying risk and cost for no benefit · Assistant readiness · What assistants such as Copilot can reach today · Which sensitive stores are open to a wide audience · Which of those carry no classification at all · What to close before a rollout rather than after an incident · What you receive · An executive report: quantified exposure, findings by category and severity · A programmatic roadmap from the scan to a governed state, phase by phase · Baseline measures your team can report against as remediation runs · Thirty days of access to the assessment platform after the readout The finding that lands hardest: Almost every assessment produces the same shape of answer: the number of people who can reach sensitive data is far larger than the number who need to. That gap is not a scandal, it is arithmetic, and it is the single most useful thing a leadership team can be shown. It converts an abstract worry into a decision about who keeps access to what, and it is the basis of every remediation plan we have run. · Access as it stands, access with a business reason, and access as it should be. The distance between the first and the last is the work. What it is not: The assessment does not remediate, enforce or monitor. It changes nothing in your estate. That separation is deliberate: you get an independent picture first, then decide what to fix, in what order, and who does it. It is not a penetration test, which asks whether someone can get in, and not a control audit, which asks whether a control exists. It asks what you hold and who can reach it. Six meetings, four to six weeks: Every assessment runs on the same rhythm. The meetings are booked up front, which is what keeps the window honest. · Scoping · Sources, priority categories and the timeline agreed with every stakeholder in the room. The first scan is kept deliberately tight: a sprawling one slows the readout and blurs the story. · Kickoff · Administrative access granted, sources configured, the first scan running. Access confirmed before this meeting is the single biggest predictor of a clean engagement. · Assistant readiness workshop · A working session on what Copilot and similar tools can reach in your tenancy, and what they would surface if asked today. · Technical results · Findings reviewed with your team, validated against the categories that matter to you, and the risk report shared. · Executive sync · The exposure and the roadmap presented to leadership in the language a board funds: what is at risk, what it would take to fix, and in what order. · Handover · What happens next, and who owns it. If remediation follows, it starts from this plan rather than a fresh discovery. What the report is actually for: A report that ends in a filing cabinet has cost you money and bought you nothing. This one exists to unlock three decisions. It tells you what to fix first, ranked by exposure rather than by whoever asked loudest. It gives finance a scope worth funding, because the work is sized against findings rather than a consultant's guess. And it gives the board and the regulator evidence that the organisation knows what it holds, which is the question underneath almost every obligation you are subject to. High counts in the findings are not a failure. They are the map.