The three lines of defence model splits responsibility for risk between three sets of roles. The first line owns and manages the risk. The second line sets the framework, monitors and challenges. The third line, internal audit, tells the board independently whether the whole arrangement works.
For ICT and cyber risk this has moved well beyond audit textbooks. DORA, the EU's Digital Operational Resilience Act for the financial sector, refers to the model directly, and the Dutch Cybersecurity Act (Cyberbeveiligingswet, the national implementation of NIS2) puts final responsibility with the board. If your lines are blurred, expect a supervisor or auditor to ask about it.
Where the model comes from
The model grew out of internal audit practice. In 2020 the Institute of Internal Auditors published an update and renamed it the Three Lines Model. Regulators and most firms still call it three lines of defence, so both names are in circulation.
The governing body sits above the lines. It is accountable to stakeholders, sets risk appetite and establishes the internal audit function. Management holds the first and second line roles, and internal audit reports to the board.
One point in the IIA paper matters a great deal when you hire: the lines describe roles, not boxes on an organisation chart. A department can contain people in two lines. A single person should not sit in both.
The three lines applied to ICT risk
First line: owning the risk
First line roles deliver the service and manage the risk that comes with it. In technology that means IT management, the teams that build and run systems, security engineers, IAM and PAM specialists and the SOC. The IIA is clear that responsibility for managing risk stays here, even when the second line is watching closely.
In practice a security engineer has to do more than deploy tooling. They need to evidence that their controls work, through logging, test results and change records.
Second line: expertise, monitoring and challenge
The second line supports risk management and reports on whether it is adequate and effective. Typical roles are the IT risk manager, the compliance officer and, depending on your set-up, the CISO. They own the framework, track the risks and push back on the first line when something does not add up.
A strong second-line IT risk manager understands the technology well enough to challenge an engineer. Their job is analysis and reporting, though, and they should stay out of the build.
Third line: independent assurance
Internal audit gives independent assurance on governance, risk management and controls. The IIA calls its independence from management critical, and ties it to accountability to the board and unrestricted access to people, resources and data. For technology risk this is where the IT auditor sits. External auditors add a further layer of assurance on top.
What DORA and the Dutch Cybersecurity Act expect
DORA is the most explicit. Its recitals refer to organising ICT risk management according to the three lines of defence model, and Article 5 makes the management body ultimately responsible for managing ICT risk. The Dutch markets regulator, the AFM, notes that DORA places great emphasis on the three lines of defence model. It expects firms to appoint both a control function and an audit function, positioned with enough independence, and an internal auditor to assess the framework periodically.
The Cybersecurity Act does not name the model. According to the Dutch National Cyber Security Centre (NCSC), though, the board is ultimately responsible, approves the security measures, oversees their implementation and has to take training. One of the ten mandatory measures covers processes for assessing whether your controls are effective.
My advice is to apply the model even if you only fall under the Cybersecurity Act. A board that has to oversee security needs someone who did not build the controls but can still say whether they work. That is the second line's job.
The common failure: one person in two lines
The CISO is the hardest call. Put the CISO in the second line and somebody else, often a security manager, has to own the controls in the first line. Let the CISO run security operations as well and they become first line, which means you need a separate second line able to challenge them.
Either set-up can be defended. What does not work is a CISO who designs the controls, has them implemented and then reports to the board that they are effective. That is marking your own homework.
The same trap opens up with contractors. An interim IT risk manager hired for the second line usually has the skills to implement as well, so it is tempting to hand them the build. A few months later they are reporting on controls they configured themselves. I would rule that out up front, in the statement of work and in the first conversation with the candidate.
Which profile to hire for each line
Decide which line a role belongs to before the request goes out. It settles who the hire reports to, what authority they get and what experience you are actually looking for.
- First line: hands-on experience with the technology you run, such as Entra ID, CyberArk or a SIEM, plus the discipline to keep evidence. We covered the access roles in privileged access management under DORA.
- Second line: knowledge of risk frameworks and your sector's regulation, and the confidence to push back on an engineer or IT manager. For supplier risk, see interview questions for a TPRM specialist.
- Third line: audit experience, independence from the teams being audited and the ability to report findings at board level.
Interim hires tend to pay off fastest in the second line. Building a framework or running a DORA gap analysis is bounded work with a clear end point. First line roles are usually ongoing operations, where a permanent hire often makes more sense.
At MVPeople we recruit interim and permanent professionals for all three lines. If you need an IT risk manager for the second line, a GRC or compliance specialist or an interim CISO, call or email me and we will start by working out which line the role belongs in.
