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鈥檛 have the business data to support their decisions. Unless you like Enron-inspired math, you can鈥檛 calculate the cost of a breach if you don鈥檛 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鈥檛 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鈥檛 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 鈥淲hich process generates the most revenue per hour?鈥� or 鈥淚f 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鈥檛 name the owner of a critical process or estimate the financial impact of downtime, the organisation is flying partially blind. Executives who claim that 鈥渢he new CISO鈥檚 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鈥檛 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
听
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鈥檛 mathematically calculate risk impact without knowing revenue at risk. It uplevels the conversation from incomprehensible 鈥渃yber 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 鈥淲e need to fix some CVSS 9.2 vulnerability鈥� to 鈥淭his 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
听
is a bridge between business processes and the technology that they鈥檙e 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鈥檛 work, because it intentionally doesn鈥檛 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鈥檙e 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鈥檚 phone number. They can鈥檛 waste time searching for the right contact, or wondering which executives need to be briefed.
听
Document 3: 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 鈥淪alesforce 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鈥檛 a multi-year maturity project or a tool to buy from a vendor, either; it鈥檚 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.
