Authoured by Kayne McGladrey
A new Chief Information Security Officer (CISO) often arrives with a mandate to secure their organisation, but in practice, they walk headfirst into the fog of war without the facts. While security leaders may ultimately be held accountable for risk decisions, they normally don’t have the business data to support their decisions. Unless you like Enron-inspired math, you can’t calculate the cost of a breach if you don’t know which systems generate revenue, or how much time the business can survive without that revenue. This helps explain why CISOs have a normal tenure of 18 – 24 months.
For CISOs with a technical background, the most frequent action is to start by assessing technical controls, often against one or more control frameworks. This is pointless without an understanding of what those controls are supposed to protect. A CISO might have their team spend weeks scanning the environment for technical vulnerabilities, but when that team can’t tell the difference between an internal support tool and a payment gateway that lacks a documented recovery plan, the resulting data are of limited use.
Before managing risk, a new leader must establish three basic documents and secure agreements with the other business leaders to write down their decisions. These documents help connect technology directly to revenue streams and operational continuity, and make cybersecurity a business function grounded in reality. Sample document templates are included with this article for readers to adapt for their own needs.
The Discovery Phase
A CISO shouldn’t sound like an auditor hoping for findings, so identifying these gaps requires a shift in conversation tone from day one. The CISO should pose questions that are reasonable for a new business leader to ask. Asking “Which process generates the most revenue per hour?” or “If that system went down tomorrow, who owns the recovery?” can produce meaningful answers.
If other executives pause while answering or give conflicting responses, this shows historically misaligned expectations. When executives can’t name the owner of a critical process or estimate the financial impact of downtime, the organisation is flying partially blind. Executives who claim that “the new CISO’s responsible” are more troubling. In both cases, it shows that risk management is based on assumptions rather than facts.
By listening to the uncertainty in other executives’ voices, the CISO gathers intelligence needed to justify the creation of new documentation. The goal isn’t to assign blame for missing data but to highlight the need to have a clearer picture of the business. This approach builds trust, and establishes the need for the collaborative work required to document processes, systems, and dependencies. As an added bonus, if your organisation needed to comply with DORA, you already likely have most of these facts. Finally, much this is work that the CISO and other business leaders will delegate to their teams for further investigation.
Document 1: The Business Process Catalogue
The Business Process Catalogue serves is the record of what the organisation actually does, who owns what, and the monetary value per unit of time. This document is important because you can’t mathematically calculate risk impact without knowing revenue at risk. It uplevels the conversation from incomprehensible “cyber threats” to concrete financial exposure that other executives understand.
Key fields in this catalog include the process name, the designated owner, revenue generated per hour or day, maximum tolerable downtime, and the specific business systems involved. The catalog uses the Responsibility Assignment Matrix principle, which requires every process to have a single accountable owner rather than a committee. This is meant to avoid decision paralysis during times of crisis.
When this data exists, it changes the conversation. A request to patch a server shifts from “We need to fix some CVSS 9.2 vulnerability” to “This patch protects a process generating $200,000 an hour.” That clarity gets other executives’ attention, and justifies resource allocation.
Document 2: The Business Systems Inventory
The Business Systems Inventory is a bridge between business processes and the technology that they’re made out of. While the Process Catalog defines value, the Systems Inventory documents the load-bearing applications and platforms. Relying on the catalog alone doesn’t work, because it intentionally doesn’t include technical dependencies or vendor relationships required to maintain or restore operations.
For first-party systems, the inventory must capture operational costs, data classification levels, and recovery objectives.
For third-party systems, fields include vendor contact information, contract location, data flow descriptions, integration dependencies, and emergency support contacts.
The RACI structure carries forward here as well. If the VP of Sales is accountable for the sales process, they’re also accountable for the CRM system that supports their business function.
This document can be re-used during incident response. When a key system fails at 2 AM on a bank holiday, the IR team needs the vendor’s phone number. They can’t waste time searching for the right contact, or wondering which executives need to be briefed.
Document 3: The Component Ledger
The Component Ledger decomposes each business system into its piece parts, covering both first-party code and third-party services. Systems are rarely granular enough for operational decision management. A single “Salesforce integration” might have an API, an identity provider, a data pipeline and an email service. Each of these components has its own vendor, failure mode, and security posture.
First-party components require version numbers, build locations, and enough data to be able to restore services, whether due to a disaster or data breach.
Third-party components require vendor contacts, service level agreements, and exit strategies to manage supply chain risk.
This level of detail is needed because an organisation is only as secure as its weakest component. When a vulnerability is announced in a software library, the Component Ledger allows the security team to quickly see which systems and business processes are affected. This enables defensible, fact-based decisions about patching priorities or risk acceptance decisions.
How the Three Documents Work Together
These three documents function as a cascading framework for ongoing business risk management.
- The Process Catalog defines business value.
- The System Inventory maps the supporting technology.
- The Component Ledger identifies hidden dependencies and risk centralisation.
Every risk calculation is visible because the data lineage is fully documented with sign-offs, which makes the math easy:
- When a component fails, you can trace it to the business system
- Then you trace the system to the process
- Finally, you reach the revenue figure, without hand-waving or guessing
This approach isn’t a multi-year maturity project or a tool to buy from a vendor, either; it’s a 100-day stabilisation exercise based on conversations, and focused on supporting revenue.
From Guessing to Governing
The first 100 days are about replacing anxiety with clarity. These three documents give you the basic facts to make decisions, the language to justify budgets, and the credibility to lead alongside other executives. Start with your three highest-revenue processes and build outward. This foundation ensures your future security investments support long-term business goals.
