00.04 The Three Lines of Defense

Why this matters

A mature GRC program separates the people who own the risks from the people who measure them, and separates both groups from the people who audit the measuring. The reason is independence: a control that's tested by the same person who designed it tells you almost nothing, because the tester has the same blind spots as the designer. The Three Lines model formalizes the separation so that independence is structural, not personal.

The model is the Institute of Internal Auditors' (IIA) contribution to GRC vocabulary, and it answers a question every program eventually faces: who's responsible for what when something goes wrong? In the Three Lines model, the answer is precisely defined. The first line owns the risk, designs the controls, and runs them day-to-day. The second line writes the risk management and compliance frameworks the first line operates within and monitors how well they're being followed. The third line, internal audit, provides independent assurance to senior leadership and the board that the first two lines are doing what they say they're doing. Three lines, three different jobs, ideally three different reporting chains.

The model isn't a one-size-fits-all rule. Small organizations routinely have one person wearing two of the three hats, or even all three on a part-time basis, and that's fine when the organization's size makes the alternative impractical. The point of knowing the model isn't to apply it rigidly; it's to know what you're trading off when your security lead is also writing the risk policy and also signing off on the audit. The trade-off is real, even when it's the right one for your size.

How frameworks describe this

The model has its own framework, and it shows up by reference in most of the others.

• IIA Three Lines Model is the canonical source. The Institute of Internal Auditors published the original "Three Lines of Defense" guidance in 2013 and updated it in 2020, simultaneously renaming it to the "Three Lines Model" to soften the adversarial framing of "defense." The 2020 update also clarified the role of the governing body and external assurance providers; the underlying three-role split stayed the same. Both names are still in active use — auditors of a certain vintage will say "Three Lines of Defense" and mean exactly what newer materials call "Three Lines Model." Treat the names as synonyms.
• NIST SP 800-53 doesn't define the Three Lines explicitly, but its AC (access control) and AU (audit and accountability) families operationalize the separation: AC-2 (account management) implements the first line's authority over operational accounts; AU-6 (audit review and analysis) implements the second line's monitoring; AU-12 (audit record generation) supplies the evidence the third line reviews. A program that's running 800-53 well has the Three Lines built into the control implementations even if nobody calls it out by name.
• COSO Internal Control — Integrated Framework describes the first and second line directly through its Control Activities and Monitoring Activities components, and references internal audit as the assurance function inside its Information & Communication structure. COSO is more boardroom-oriented than the IIA model, but the underlying separation is consistent.
• ISO/IEC 27001 clauses 5 (Leadership) and 9 (Performance evaluation) carry the model implicitly: clause 5 places risk-management accountability with top management (governance), clause 9 mandates internal audit (third line), and the operational requirements scattered through clauses 6 through 8 are first-line work performed under the second line's framework. The standard doesn't name the Three Lines but assumes them.

When a framework doesn't name the Three Lines, look for the separation in its access-control and audit clauses; it's almost always there in some form.

How SimpleRisk implements this

SimpleRisk doesn't impose the Three Lines model on customers, but its permissions, teams, and roles model is built to support the separation when an organization wants to enforce it. The mapping is direct.

First line (operational management) maps to the risk owner field on each risk and to the control owner field on each control. SimpleRisk requires a named owner on every risk and supports per-team segregation so that risk owners only see the risks for the teams they belong to (see Team-Based Segregation). The first-line user has permissions to submit risks, edit risks they own, and submit evidence for control tests on controls they own. The day-to-day work of running the controls is theirs.

Second line (risk and compliance functions) maps to users with permissions to install and configure frameworks, define the scoring methodology, schedule control tests, review and approve risks submitted by the first line, and manage the policy library. These are the SimpleRisk users who define the program rather than operate it. The second line typically has broader visibility across teams than the first line, because their job is to monitor consistency across the organization. The permission keys and how to assign them are documented in The Permission Model and the full inventory in Permission Reference.

Third line (internal audit) maps to a read-only user with broad visibility but no edit rights — typically a user assigned to a "Read Only" role with permissions to view risks, controls, evidence, audit logs, and reports across all teams, and no permissions to modify any of them. The audit user's job is to verify, not to operate; the SimpleRisk permission model lets you create exactly that user without granting any side-effect-bearing capabilities. For organizations with external auditors as well, the same pattern works: provision a time-limited audit account that sees everything and changes nothing.

The system isn't prescriptive about how rigorously you separate the lines. A startup may run all three from one user account because there's only one person doing GRC work; a Fortune-500 company may run separate teams of dozens for each line, with separate reporting chains all the way to the audit committee. SimpleRisk's job is to make the separation possible without forcing it. See Separation of Duties for the patterns we see customers use most.

Common pitfalls

The Three Lines model is straightforward to state and harder to operate. Failures cluster in a handful of patterns.

• The "third line" who reports to the second line. An internal audit function that reports to the CISO (the second line, in most organizations) isn't independent of the second line's work, by definition. The model breaks the moment the audit findings have to be approved by the people being audited. The fix is structural: internal audit reports to the audit committee or the board, not into the operational chain. Smaller organizations often can't afford the independence; in that case, name the gap and consider an external auditor for high-stakes engagements.

• One person, three lines, one budget. A small program where the security lead designs the controls (first line), writes the risk policy (second line), and tests the controls themselves (third line) isn't broken by virtue of the overlap, but the program needs to know the independence is missing. The compensating control is usually rotating an external assessor through the third-line role on a defined cadence — quarterly, annually, before a major audit.

• The first line that's also the auditor. A control owner who fills out their own evidence form and marks the control as passing is doing first-line and third-line work on the same control. The whole point of the separation is to catch the cases where the operator doesn't want the control to fail. Build the workflow so the test reviewer is someone other than the test performer; SimpleRisk's per-control owner field plus the test-review permission are designed for exactly this split.

• The second line that's actually first-line work in disguise. "We have a compliance team" sometimes means "we have a team that fills out evidence forms for the first line because the first line is too busy." That isn't a second line; it's a first-line shadow. The second line's job is to define the framework and monitor adherence, not to perform the work. When the second line is doing first-line tasks, the framework definition starts to drift to whatever's convenient for the team that's actually performing the work, and the independence collapses.

• Ignoring the model because the org is "too small." Small orgs do need to know the model even if they can't fully implement it. The trade-off awareness is what distinguishes a small program that knows it's running three roles in one head from a small program that doesn't realize the structural risk it's carrying. The first one buys the right insurance — an external assessor, a peer-review cadence, a board-level reporting line; the second one finds out about the missing independence the first time something goes wrong.

• Treating the 2013 vs. 2020 rename as a substantive change. Some programs spend meeting time debating whether to call it "Three Lines of Defense" or "Three Lines Model" as if the rename mattered to the work. The IIA renamed it for tone; the underlying three-role split is unchanged. Pick whichever name your stakeholders use and move on.

Related

• What is GRC?
• What is Governance?
• Managing Users, Teams, and Roles
• Separation of Duties