Case Studies

Three programs, in the order I ran them, each bigger than the last: an asset baseline an authority had never built, a data policy that held up under a defense manufacturer’s audit, a risk workflow a SAMA-regulated bank’s Operational Risk Committee now reads from. Foundation, then governance, then optimization. One thread runs through all three: making NCA, SAMA, PDPL, and ISO 27001 line up against a single control set instead of four.

01

Building the Asset Inventory the ECC Assessment Was Built On

The inventory became the system of record for NCA-mapped control evidence.

General Authority for Statistics · 2021–2022
Foundation · NCA ECC · Asset Management
Context

The organization was preparing for its first compliant assessment against the National Cybersecurity Authority’s ECC framework. On paper there was a security function, training programs, and tooling. On the ground, the most fundamental control was missing: nobody could tell me, with confidence, what we owned, who owned it, or how critical it was.

Challenge

You cannot defend, classify, or assess risk against assets you cannot enumerate. Every other control in the ECC framework (access management, vulnerability handling, incident response, supplier risk) assumes an asset inventory exists. We had spreadsheets in different formats across IT, legal, and procurement, no agreed definition of an “asset,” and no system of record. The first compliant assessment was less than twelve months away.

Approach

Rather than negotiate a perfect inventory standard with five departments, I built one. I designed the organization’s first end-to-end asset management tracker from scratch, with principles I refused to compromise on: every asset has one owner, a sensitivity tier driven by data not hardware cost, a refresh cadence on a calendar, a named evidence owner, and one declared source-of-truth system per record.

I conducted interviews, pulled data from procurement, network discovery, and Active Directory, and reconciled what they disagreed on by forcing decisions in the room rather than guessing. The tracker started simple. It stayed simple on purpose.

My role: I designed the asset schema and ran the cross-functional reconciliation; IT, procurement, and the network team supplied the source data.

Outcome
  • Became the system of record that 25+ NCA-mapped controls drew their evidence from.
  • Stood up the inventory the organization’s first compliant ECC assessment was built on: the prerequisite every other control depended on.
  • Gave every later risk assessment, vulnerability program, and audit cycle a stable base. Auditors stopped asking “are you sure this is everything?”
What I Learned

In compliance-heavy environments, teams jump to implementing the headline controls (DLP, SIEM, IAM) without fixing the foundation underneath. Inventories you maintain beat perfect ones that no one updates. Build the boring thing first; everything else gets cheaper.

02

Authoring a Data Policy That Held an Audit Together

The NCA DCC domain reached 100% on its first audit.

SAMI AEC (Saudi Arabian Military Industries, Advanced Electronics) · 2023–2024
Governance · NCA ECC/DCC · CST · PDPL
Context

I joined as Cybersecurity & Data Protection Specialist to bring the organization into alignment with NCA requirements (ECC and DCC), CST controls, and PDPL ahead of a fixed audit window.

Challenge

Authoring a policy on its own is not hard. Getting it adopted is. In any organization, the gap between “policy approved by the board” and “every staff member actually following it” is where most compliance programs fail. I had a fixed audit window and a set of known control gaps, each one a finding waiting to happen if it was still open on audit day.

Approach

I wrote the organization’s first organization-wide data policy from a blank page, anchored on three deliberate design decisions:

  • Short and operationally enforceable. No aspirational language nobody could measure.
  • Every clause traceable to a control. Each line tied to a specific NCA control, PDPL article, and ISO requirement, so adoption tracked compliance directly.
  • Sequenced rollout, not big-bang. Classification first (because everything else depends on it), then handling rules, then exception process, staged against the audit timeline.

I ran the executive workshops, designed the staff awareness program, and built the compliance tracking myself, so I could see week by week where adoption was lagging and close the gaps before the audit window shut.

My role: I authored the policy and mapped every clause to its NCA, PDPL, and ISO control; the SOC and endpoint teams ran the DLP and FIM rollout. The DRM deployment I did myself alongside the vendor engineer, and I debugged the classifier integration and the DLP file-type coverage gaps hands-on.

Outcome
  • Every control gap in my scope closed and verified at re-audit, inside the audit window.
  • Compliance against the NCA control set improved substantially by the next assessment, and the data protection domain (NCA DCC) reached 100% on its first audit.
  • Policy rolled out to every staff member, with adoption tracked weekly so lagging areas were fixed before the audit, not after.
  • DLP and File Integrity Monitoring rolled out with the SOC and endpoint teams, consolidating data-egress visibility under the new policy.
  • Enterprise DRM deployed hands-on with the vendor engineer, including the network, traffic, and device encryption groundwork it depended on. The data-classification integration was repaired and DLP detection gaps closed on file types the policies had missed.
  • The policy became the governance baseline the later NCA, ISO 27001, and PDPL work all built on.
What I Learned

Policy is the contract that holds the rest of the control stack up. If it’s too long to read, it doesn’t get followed. Keep it short, tied to controls, and adoption tracks compliance.

03

Re-engineering a SAMA Bank’s Risk Workflow Without Replacing It

One workflow now surfaces findings and tracks them to closure.

Confidential SAMA-regulated bank · 2024–Present
Optimization · SAMA ITGF · 3LoD · Board Reporting
Context

I lead enterprise-wide risk assessments across IT and cybersecurity at a SAMA-regulated bank, aligning 200+ controls with SAMA’s IT Governance Framework (ITGF). The bank had a mature risk function: established Jira-based workflows, a long history of regulatory examinations, and three Lines of Defence active in parallel. The challenge wasn’t building from scratch. It was getting something mature to produce sharper data without breaking what already worked.

Challenge

Mature risk functions accumulate a predictable tax. Assessment cycles stretch when evidence is collected again. Documentation forks across audit, compliance, and IT. Key Risk Indicators may sit apart from Key Performance Indicators and residual-risk scoring, leaving a board with correct data but a fragmented picture. The same risk then gets reviewed in three forums because no single record is trusted as the answer. None of that is a control failure. It is avoidable cost.

Approach

I re-engineered the Jira-based risk workflow rather than replacing it, which would have forced a years-long migration and likely failed. Inside the existing toolchain, I embedded KRIs, KPIs, and residual risk scoring directly into the risk record (with treatment states that include defer-with-expiry, so nothing parks indefinitely), and a single workflow produced data fit for three audiences: the assessor, the treatment owner, and the board.

I then unified risk treatment documentation across audit, compliance, and IT into a single source of truth, eliminating the divergence that was wasting cycle time and creating reconciliation work. One boundary stayed deliberately intact: internal audit keeps its own independent conclusions. The shared record supplies lineage, not the verdict. To close the loop with the threat side, I integrated threat modelling and asset sensitivity data into the risk register so control-mapping accuracy improved without adding new tooling.

My role: I re-engineered the workflow, embedded the KRI/KPI/residual scoring, and unified the documentation; the wider risk function drove adoption across the three lines.

Outcome
  • Cut risk-assessment cycle time from weeks to days by moving scoring and evidence collection into the workflow itself.
  • Findings were surfaced and tracked to closure inside one workflow instead of three.
  • Board risk reporting moved from a periodic exercise to a near-live view.
  • Three Lines of Defence reporting became consistent for the first time.
What I Learned

Mature shops rarely need new tools. They need the ones they have to produce data the board can act on. Re-engineering inside what’s already running usually beats migration projects.

Have a similar problem?

I’m open to leadership and advisory work across cybersecurity, technology risk, privacy, and GRC in SAMA-, NCA-, or CST-regulated organizations.

Discuss a Role