Technology Risk Management: What to Look For

Comair, then flying as a Delta Air Lines subsidiary, capped its crew-scheduling system at a fixed number of schedule changes a month. That ceiling was a documented property of the software. A peak Christmas season pushed past it, the system refused further changes, and the airline grounded its flying with close to 200,000 passengers stranded across the United States. LeanIX's guide to technology risk management puts the revenue loss near US$20 million and records the ceiling as a known limit of that system. No item on the risk register was red the day before.

That gap is the discipline worth testing. Technology risk management is the body of facts about your estate that keep holding between reviews, and the worth of a programme is the length of the gaps it can survive. A framework, a certificate and an annual review each hold a place. The month the ceiling gets reached has no use for any of them.

Every check below is a property of your own estate. You will know which side of it you are on, and a mistake is work to do. The sections run in the order the checks happen, because the same question asked at the wrong moment creates a document where a decision was wanted.

Before a framework earns its place

You can list every application that carries a regulated process, together with the version of each component underneath it. Where that list came out of a configuration management database last reconciled two quarters ago, the answer is no, and the framework decision is premature.

Each unsupported component has a vendor support expiry time in the register assigned to one owner. LeanIX's guide reports that most organisations handle the introduction of technology far better than its retirement, and that running unsupported technology stays expensive. That asymmetry is the whole problem. A retirement plan that never reaches a formal order is a wish.

Retirement has its own budget line, and the person who signs it occupies a different post from the person who approves new acquisitions. Payments cease whenever the year is tight if obsolescence is funded from whatever remains at year end.

Grant Thornton's technology risk services work across all three lines of defence, and that frame is correct: the first line owns the control, the second challenges it, and the third tests whether the first two told the truth. Ask which line owns each item you have just listed. Where two lines both claim the same control, one of them is guessing.

KPMG's technology risk practice identifies the exposures it works on, putting data privacy, cyber security, cloud implementation and third-party assurance alongside ageing infrastructure and applications as the pressures on business continuity, and tying all of them to regulatory breakdown, reputational damage, financial loss and the loss of critical services. Read that list as a checklist. An item with no owner known within your organisation is a gap that a framework acquisition would otherwise cover.

Systems nobody remembers procuring

The scope reaches systems nobody remembers procuring, and those carry the weakest lifecycle data. An assessment that starts from the applications the IT department likes yields a clean result about the wrong population.

Every application links to a business process, and that process has an owner outside IT who is accountable for it. LeanIX's five-step method places the linking of software and servers to applications fourth, behind the inventory, the software versions and the servers themselves, because dependency is what turns a component breakdown into a business outage. A register of components without dependencies tells you what is old and stays silent about what will cease to function.

Shadow estates are the test. List the applications acquired on a department card, the spreadsheets that feed a regulatory return, and the integrations nobody documented at handover. If any of those are outside the register, the boundary of your programme is the boundary of your filing system, and the two are different forms.

Controls that leave evidence

A control can be handed to somebody who has never seen the system, and that person could perform it from the instruction alone. Many controls are a line in a spreadsheet, recorded by the person who then marks the test passed. That control has never been tested.

Evidence is available before an auditor asks for it: a file, a log, a signed record. Mitti's guide to technology risk management sets out five steps, identifying, assessing, mitigating, monitoring and reviewing, and the review step is the one organisations skip. A control that creates no record between reviews is a belief.

A person who does not own the risk performs the test, and the tester's identity is on the working paper. Remediation has a deadline and an owner. If a finding is accepted, ask who accepted it and whether that person can explain the loss they agreed to carry. Risk acceptance by somebody without the authority to lose the money is deferral with better typography.

What a review should have moved

Risk is expressed in money or in time. A register of red, amber and green provides no information that a board can use to take action. Where the language is probability against impact, the estimate traces to something: the value of the agreement, a published range for fines, and the calculated cost of the last outage. Those are available for inspection.

The register moves between reviews. Where the last three months brought no change, either the estate is unusually static or the register is an annual event. LeanIX's guide records that 67% of CIOs rate their technology risk management as ineffective, that 72% of organisations bring technology risk teams into projects once problems have appeared, and that 47% adopt technologies such as mobile apps and devices without putting them through a risk assessment. Those numbers are a list made for the reviewer.

The end-of-life list stays short enough to act on this quarter. The same LeanIX guide records that auditors found the United States Internal Revenue Service unable to account for roughly 1,300 Windows XP machines, about 1% of its total, nine months after Microsoft withdrew support, and that the agency was funding post-retirement support agreements with Microsoft to keep receiving critical security updates. A list you can only add to is an inventory of postponed decisions.

Money the programme has to earn

The programme cost is compared to a loss amount, and somebody has recorded that loss. LeanIX reports that the cost of non-compliance is commonly put at about 2.5 times the cost of compliance, which gives a useful shape to the argument. Your own number does the work. Regulators fine inside published ranges, and an outage costs what your last one cost.

Three types of programme compete for the same budget, and each one breaks in a way you can predict before you sign.

An audit-led assurance programme acquires sampled evidence and a formal opinion. Its cost is the audit fee. You have an opinion, and the way it goes wrong is a clean opinion signed over a control nobody changed.

An inventory-led platform programme acquires a continuous record of applications, versions and dependencies. Its recurring cost is a licence per application plus the staff needed to keep the record current. You have a populated register, and its risk is that no decision has ever come out of it.

A decision-led programme acquires a set of options priced against decisions with owners and times attached. Its cost is the fee plus the executive hours those decisions consume. You have decisions taken, and the way it goes wrong is that the decisions were too small to matter or landed after the money had been spent.

Take the shape against the decision you need taken. A programme that cannot identify the decision it serves is a cost centre with a risk register attached.

The hour an incident starts

The ceiling on the Comair system was known. What was missing was a decision taken in advance about what the business would do when the limit came within reach. That decision belongs to the business owner of the affected service, and it is the check most programmes skip.

For the three services whose loss would hurt most, a recorded decision sets out what the business does when the system degrades, who makes that call, and what the manual process is. Anything you have to invent during the incident is not a plan.

A call tree is current, and it was exercised out of hours within the last twelve months. One incident commander is appointed, and that person is not the head of IT, since the head of IT will be inside the problem.

Each critical service has a recovery time objective agreed with its business owner, and that owner can state the figure without opening a document. Restoration from backup was tested within the last twelve months, and the test restored onto infrastructure that did not depend on the system being restored. Restoring a backup onto the same broken platform proves very little.

Somebody carries authority to spend during the first hour without convening a committee. Where no such authority is recorded, the first hour goes on approval, and recovery begins later.

What third parties add to the register

LSEG's third-party risk management for technology companies sets out the screening it runs across a global supply chain and distribution network, covering sanctioned entities, exposure to bribery and corruption, theft of intellectual property and counterfeiting. The same page sets out the data and cyber exposure that comes with a long supplier list. Those are the categories to test against your own register.

Every supplier that touches a regulated process appears in the register with an owner inside your organisation. The supplier's own sub-processors appear beneath it, because the tier below your supplier carries the same service. The arrangement carries a right to audit in its terms, and that right was exercised at least once.

An exit plan is recorded for each critical supplier, and it sets out how the service moves or is rebuilt, over what period, and at what cost. Where two critical services rest on one provider, concentration is on the register as a risk in its own right.

Third-party risk runs the length of the relationship rather than the onboarding window. Grant Thornton's technology risk services list third-party risk among the areas they cover, and that is the right place for it: the tier you do not screen is the tier you will be asked about.

The reporting regime you will answer to

Grant Thornton's technology risk services record that the FCA's Operational Incident and Third-Party Reporting regime brings third-party outages into the scope of formal reporting for the first time. A supplier outage becomes a reportable event with a clock attached, where it was an internal operational matter.

Which of your incidents are reportable, who makes that call, and how soon must the first notification go in? Where the answer depends on somebody reading the rules once the event has started, the reporting decision will be late.

For each provider carrying a regulated service, a mapping joins the obligation you owe the regulator to a specific control that provider operates. Google Cloud publishes compliance mappings to the MAS Technology Risk Management Guidelines for Google Cloud and Google Workspace, so that a financial institution can assess it as an outsourced service provider. The Monetary Authority of Singapore established those guidelines to guide financial institutions on technology risk governance and oversight, and on maintaining IT and cyber resilience. Ask every provider for the same mapping, whether or not it publishes one.

Sources

• Technology risk management | KPMG UK
• Technology Risk Management - The Definitive Guide | LeanIX
• Technology Risk Management: A Short Guide | Mitti (by SafetyCulture)
• Technology risk services | Grant Thornton
• MAS TRM Guidelines - Compliance | Google Cloud
• Risk Management for Technology Companies | LSEG