Definition

The Three Lines of Defence (3LoD) model assigns risk accountability across business operations (first line), risk and compliance oversight (second line), and independent assurance (third line / internal audit). In cloud-native banks, DevSecOps pipelines blur first- and second-line roles because engineers embed security controls in CI/CD; the model must be redesigned to define explicit hand-off artefacts — not simply assumed to be replaced by automation.

Why it matters

The pressure on GRC Advisory programmes is shifting in specific, observable ways:

• SAMA CSF 2.0 Section 3.3.5 and CBUAE IAR Art. 9 both require a documented 3LoD assignment; examiners in 2024 UAE inspections cited DevOps-only security postures as a second-line gap.
• IIA's 2020 Three Lines Model (which replaced the legacy 3LoD) requires each line to have explicit accountability statements — DevSecOps tools like Snyk or Wiz generate findings but do not constitute a risk challenge function.
• Cloud-native change rates (200–800 deployments per day in mature organisations) mean manual second-line review of every release is impossible; structured hand-off artefacts (policy-as-code gates, automated SoD checks) are the practical answer.
• Internal audit reliance on automated pipeline outputs (e.g., DAST results, IaC scan reports) is accepted by Big-4 auditors only when second-line review of tool configuration and exception handling is documented.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• CI/CD pipeline gate logs (GitHub Actions / GitLab CI) — policy-as-code rule ID, pass/fail result, PR author, merge approver, timestamp.
• Second-line risk opinion register — control design review sign-off by Risk Manager, date, change ticket reference.
• Internal audit universe and annual plan — first-line and second-line coverage mapped, reliance rationale for automated evidence documented.
• SoD conflict report from IGA tool (SailPoint / Saviynt) — conflict ID, remediation action, sign-off by second-line.
• Board audit committee charter — 3LoD accountability table with named role titles, approved date.

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: CRO and Head of Engineering jointly produce a 3LoD accountability matrix covering all ISO 27001:2022 Annex A controls; identify where a DevSecOps tool is falsely labelled as 'second-line oversight'.
• Day 31–60: Risk Manager defines five mandatory hand-off artefacts for each production release (e.g., threat-model sign-off, dependency scan exception log, IaC policy gate result) that constitute first-to-second-line transfer.
• Day 61–90: Internal Audit Head updates audit universe to include CI/CD pipeline configuration reviews as a third-line activity, targeting two pipeline audits per year.
• Day 90+: Quarterly 3LoD effectiveness review chaired by CRO; outcome documented in board risk committee pack with red/amber/green line-by-line status.
• Ongoing: Second-line Risk Analyst reviews automated tool configuration (Snyk, Wiz, Checkov) monthly to confirm rules remain aligned with UCF control requirements; findings logged in ServiceNow GRC.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Percentage of production deployments with all five mandatory hand-off artefacts present — target 100%.
• Second-line risk opinion cycle time (change submitted to sign-off) — target ≤2 business days for standard changes.
• Internal audit findings attributable to second-line hand-off failure — target 0 repeat findings across two consecutive audit cycles.
• Percentage of Annex A:2022 controls with documented 3LoD accountability assignment — target 100%.
• CI/CD policy gate pass rate without exception override — target ≥97% of pipelines per month.

The executive frame

For an executive sponsor, the decision behind this piece reduces to three questions: what changes in the next two quarters, what is the cost of not acting, and what is the minimum credible response?

Held against the board risk committee and external auditors covering ICFR, the answer is rarely "do nothing" — but it is also rarely "rebuild the programme". The honest answer for most GRC Advisory buyers is a sharply scoped uplift focused on the two indicators that move the most: % of controls with a named owner and last test date ≤365 days and open issues by age and severity.

• What changes. The supervisory bar has moved on operating evidence, not on the control text itself.
• Cost of inaction. Findings carried into the next cycle compound; remediation in a regulator-driven timeframe costs 3–5× what proactive remediation costs.
• Minimum credible response. A 90-day uplift focused on the two indicators above, with a board-level commitment to the next review point.

Pitfalls we keep seeing

Across MAST Consulting Group's GRC Advisory portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: issue tracker maintained in parallel by audit, risk and compliance. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: risk appetite statement that the second line cannot operationalise. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: duplicate controls across ISO/SOC/PCI catalogues with no master mapping. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: KRIs that move but no one is accountable for the response. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on GRC Advisory engagements because the integrations are cheap and the evidence is defensible:

• or a deliberately spreadsheet-and-Confluence stack for early-stage programmes — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• BI tools (Power BI, Tableau) for board dashboards — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• GRC platforms (Archer, ServiceNow IRM, OneTrust) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs GRC Advisory programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this briefing is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for GRC Advisory programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.