Index / Context

What a Mature Programme Looks Like

kind
Reference
domain
Assurance
stage
Context
read
3 min
assumes
No prior programme in place

A description of the end state, so that intermediate stages can be judged against something other than the vendor's roadmap.

Maturity models in this field tend to describe increasing tool coverage. A more useful description is behavioural: what does an organisation that handles this well actually do?

It knows what it is protecting

A written list of data categories that matter, agreed with the business, reviewed annually. Between six and fifteen items, each with an owner outside security.

Not a comprehensive catalogue. A prioritised one.

It knows where those categories live

Including the copies. The inventory covers systems of record and the extracts, reports and shares that accumulate around them, and it is maintained rather than produced once.

Access is narrow and reviewed

The number of people who can reach each sensitive category is tracked and trending down. Access is reviewed at role change, not only annually. Third-party access expires by default.

This is the measure that most reliably distinguishes a mature programme, and it has nothing to do with detection.

The alert queue is fully reviewed

Every day, by a person, with attention. The volume is single digits to low tens because the detections are precise, not because thresholds were raised.

If nobody can review everything, the programme is a log regardless of what else is true.

Detections are maintained artefacts

Each has a purpose, an owner, documented exclusions with review dates, a measured false positive rate and a test. They are version-controlled outside the product. Ones that produce nothing are retired.

Governance is written and honoured

Who can request an investigation, who approves, who sees raw data, what triggers HR and legal. Access to monitoring data is itself audited, and that audit is reviewed outside the team.

Employees have been told what is monitored and what it is not used for.

Response is rehearsed

There is a written procedure someone can follow out of hours. The authorisation path for access suspension is known in advance. Preservation happens before containment. Legal is involved from the start.

The whole path has been walked through on paper at least once, and the gaps found were fixed.

Departures are handled deliberately

Resignation triggers a review automatically. Access narrows to what handover requires. The preceding weeks are examined. An explicit conversation about ownership happens.

This one process addresses more real incidents than everything else combined.

It measures process, not drama

Time from event to review. Proportion of alerts reviewed. Categories covered against the inventory. Access population per category. Repeat rate after intervention. Time to revoke access on departure.

Not alert counts.

It states its limits

The programme knows and says what it cannot see. Executives have heard it. Nobody in the organisation believes data loss is prevented, because nobody has been told it is.

What is absent

No surveillance capability beyond what the stated purpose requires. No screen recording or keystroke logging deployed because it came bundled. No indefinite retention. No monitoring the workforce was not told about.

These absences are as much a feature of maturity as any capability, and they are what makes the programme survivable over a decade rather than until the first challenge.

The honest note on timelines

Reaching this takes years, not quarters, and most of the work is organisational rather than technical.

An organisation that has done the inventory, reduced access and built the departure process — with no DLP product at all — is further along than one that deployed a platform and skipped those. The tooling accelerates a functioning programme. It does not create one.