Three Lines of Defence

Structuring Risk Ownership and Assurance

The Three Lines of Defence is a governance framework that splits responsibility for risk into three distinct roles: the people who run the business and own the risk, the specialists who set standards and challenge them, and an independent function that gives the board assurance that both are working. The Institute of Internal Auditors (IIA) renamed it the Three Lines Model in 2020, dropped the word "defence", and refreshed it again in July 2026 — but the core idea is unchanged: nobody should be marking their own homework.

For a CTO, this is the model that decides who owns a risk, who gets to challenge the owner, and who tells the board whether any of it is actually true.

The Three Lines

First line: management and operations

The people closest to the work own the risk. They design and run the processes and controls, and they carry the consequences when those controls fail.

• Owns risk day to day, including assessment, mitigation, and acceptance.
• Closest to the detail — real-time knowledge of what is actually happening, which no oversight function can match.
• Not independent by design. Objectivity is constrained because you are assessing your own work, which is exactly why the other two lines exist.

Second line: risk, compliance, and specialist oversight

Specialist roles that support, monitor, and challenge the first line. They set the framework, define standards, watch the metrics, and push back when the first line drifts.

• Provides expertise in risk, compliance, security, quality, and similar domains.
• Challenges and supports rather than simply policing: a second line that only says "no" becomes a bottleneck, and a second line that only collects paperwork adds no value.
• Part of management, but typically separated from day-to-day operations so it can maintain enough objectivity to be heard.

Third line: internal audit

An independent function that reports functionally to the board (usually the audit committee) and gives objective assurance on how well the first and second lines are doing their jobs.

• Highest independence: unrestricted access to people, data, and information, and the ability to escalate without management filter.
• Holistic view across all operations, functions, and risk areas.
• Periodic by nature — risk-based assurance means lower-risk or emerging areas may go unreviewed for a while, which is a limitation worth acknowledging.

Two points the diagram hides but the IIA stresses: these are roles, not boxes on an org chart. Individuals and teams can hold a mix of first- and second-line roles, and the model deliberately avoids prescribing structure. And independence is not isolation — the third line should collaborate freely with the other two, as long as it never takes on management's responsibilities.

From "Defence" to "Model"

The original framing (IIA, 2013) was purely defensive: three layers of protection against things going wrong. The 2020 update made three shifts that matter to how you run an engineering organisation:

1. "Defence" was removed. Risk-based decision making is as much about seizing opportunity as avoiding loss — value creation as well as value protection.
2. It became principles-based rather than structural. Six principles, explicit permission to blend or separate lines, no one-size-fits-all org chart.
3. The governing body moved to the centre of the graphic. The board sets purpose and risk appetite, delegates authority, and receives assurance — it is not a passive audience floating above the lines.

The July 2026 Statement of Position goes further, centring the document on coordination and reliance between the lines: reduce duplication, close gaps, and give the board one coherent view of risk instead of three conflicting reports. It also addresses the awkward case where the chief audit executive takes on second-line responsibilities — permitted, but only with safeguards that protect the function's independence and objectivity.

Mapping the lines onto a technology organisation

Note the traps in that table. A penetration test run by the team that built the system is a second-line (or first-line) activity, not third-line assurance — self-review undermines the independence the model exists to protect. Likewise, if your security team both defines the controls and signs off that they are effective, you have collapsed the second and third lines and lost your independent check.

External assurance sits outside the model but feeds it: statutory external audit, regulatory inspections, and accreditation bodies provide assurance to outside stakeholders, and their findings should be fed back into the same picture rather than kept in a separate silo.

Strategic Utility: Why CTOs Should Care

1. It ends "everyone owns risk, so nobody owns risk"

The single most common failure in technology risk is diffuse ownership. The three lines force a named first-line owner, a named second-line challenger, and a named source of board assurance for every material risk.

2. It protects engineering throughput

A well-run second line publishes standards once instead of negotiating every exception separately. Teams get a paved road — clear controls, clear evidence expectations — rather than surprise gate reviews. A bad second line does the opposite: tickets, waivers, and approval theatre.

3. It gives you a clean story for the board and for due diligence

Investors, acquirers, and regulators all ask the same question: how do you know your controls work? "First line runs them, second line monitors and challenges, third line assures, here is the coverage map" is a far stronger answer than a list of tools.

4. It stops assurance sprawl

Without coordination, three functions audit the same access-control process while an emerging AI or supply-chain risk gets zero coverage. Annual assurance mapping — who covers what — is cheap insurance against both duplication and blind spots.

5. It clarifies reporting lines

Third-line independence is established through structure: functional reporting to the board or audit committee, administrative reporting to the CEO, unfettered access to data, and freedom from interference in scope and planning. If your internal audit function reports only into finance or engineering management, that is a governance gap worth raising.

Common Failure Modes in Tech Organisations

• The second line becomes a bureaucracy. Risk and compliance teams measured on tickets closed rather than risks reduced will optimise for paperwork. Give them authority and a seat in planning, not just a queue.
• The first line outsources its risk. "Security will catch it" is a first-line failure. Controls closest to the work are the cheapest and fastest ones.
• The third line is too far from the code. Findings engineers cannot act on get closed as noise. Bring technically credible people into audit, or pair auditors with engineering counterparts.
• Self-review. Designing a control and later assuring it — the same person, team, or tool owner — breaks objectivity. When lines must overlap, document the safeguards.
• The risk register graveyard. A register nobody status-checks is not a control. ROAM forces an explicit decision on every entry; RAID keeps assumptions and dependencies visible alongside risks.

Practical Application Steps

1. Write a one-page ownership map for your ten biggest risks: who owns it (first line), who challenges it (second line), who assures the board on it (third line). You will find gaps immediately.
2. Keep roles, not org charts. In a small company the lines will blend — that is fine. What must stay separate is the independence of anyone providing board-level assurance.
3. Make second-line standards self-service. Publish the control expectations once; let teams meet them through normal delivery rather than through meetings.
4. Review assurance coverage annually, retire duplicated reviews, and redirect the effort to uncovered risks.
5. Never let internal audit own the controls it audits. If the chief audit executive takes on second-line duties, put explicit safeguards in place and disclose the arrangement to the board.
6. Treat external findings as input. Feed penetration test results, audit reports, and regulatory feedback into the same register the three lines use — one source of truth, one set of owners.

Explore Next

• ROAM Risk Management — A practical way to give every identified risk a status and an owner.
• The Swiss Cheese Model — Why layering independent controls beats relying on any single safeguard.
• RAID (risks, assumptions, issues, dependencies) — The register most first-line teams actually keep day to day.
• Technical Pre-Mortems — A first-line habit for surfacing risks before kickoff instead of after the incident.

References

• Statement of Position on the Three Lines Model (2026) — The IIA's current position paper, published July 2026, replacing the 2020 update.
• The IIA's Three Lines Model (2020 position paper) — The update that renamed the Three Lines of Defence and re-grounded it in six principles.
• Three lines (Internal audit)Wikipedia — Neutral overview of the model, its history, and later variations.
• Explained: The new Three Lines Model — Chartered IIA's plain-English walkthrough of what changed and why.
• Three Lines Model for risk management gets major update — Coverage of the 2020 rename and the shift from defence to value creation.