Accountable for controls you do not own
The compliance function owns the frameworks and none of the controls. IT owns access, HR owns training, Legal owns contracts, Procurement owns vendors. Every piece of evidence you need belongs to someone who does not report to you — and the regulator holds you responsible anyway.
The structural problem in every compliance function
From the compliance programmes we build and run in Saudi Arabia: the compliance team is accountable for an organisation's regulatory position and operates almost none of the controls that produce it. Authority sits in the departments; accountability sits with compliance. That gap is where programmes fail, and no amount of effort from the compliance team closes it.
This is not a criticism of how enterprises are organised. It is the correct structure — access control genuinely belongs to IT, and awareness training genuinely belongs to HR. The problem is what happens between them, where a control is implemented by one function, evidenced by another, and reported by a third who saw neither happen.
Access control, encryption, logging, vulnerability management, change management, backups. The largest share of technical controls in every framework, owned by a function with its own roadmap and its own priorities.
Awareness training, screening, onboarding, the joiners-movers-leavers process. Controls that fail quietly, because nobody notices an access revocation that did not happen.
Contract clauses, processing agreements, regulatory interpretation. Often the function that decides what a requirement means, without owning what happens next.
Vendor onboarding and the supplier requirements attached to it. The function most able to enforce third-party controls and least likely to be told they exist.
Physical access, environmental controls, secure disposal. Consistently forgotten until an assessor asks for the visitor log.
The processing activities, the data, the actual risk. They rarely see themselves as part of the compliance programme, which is precisely why their records are the ones missing.
Every one of these has a day job that is not compliance. A programme that depends on their goodwill works until the quarter gets busy, which is the same quarter the assessment falls in.
And you are not running one framework
A Saudi enterprise typically carries four or five simultaneously, assessed by different parties on different schedules.
| What you carry | Because | Assessed by |
|---|---|---|
| NCA ECC | Critical national infrastructure, or work for government entities | The NCA, and the entities you supply |
| Sector framework | Your regulator issued one | That regulator, on their cycle |
| Saudi PDPL | You process personal data | SDAIA, and every data subject who asks |
| ISO 27001 or SOC 2 | A customer asked, and the deal depended on it | A certification body or CPA firm, annually |
| Customer requirements | Large buyers issue their own control sets | The customer, during vendor review |
| Internal policy | Your board expects more than the minimum | Internal audit |
The overlap between these is large — access control appears in all six — but managed separately they generate six requests to the same engineer for the same evidence within one quarter. That is not a compliance problem; it is a credibility problem, and it is why the sixth request gets ignored.
What changes in Govrly
The gap between accountability and authority does not disappear. It becomes visible, which is most of the battle.
Implement once, satisfy several
An access control implemented once satisfies an ECC requirement, an ISO Annex A control, a PDPL safeguard and a customer's contractual clause — from the same record. The overlap you know exists becomes something the system acts on.
Named people outside your team
Each control carries an owner in the function that operates it, with a target date. Not the compliance manager by default, which is what a spreadsheet quietly produces.
Requested once, reused everywhere
The artefact proving a control operates is requested from the person who produces it and then supports every framework mapped to it. One request instead of six, which is the difference between cooperation and avoidance.
Evidence expires on its own
A penetration test valid in March proves nothing in December. Evidence carries a validity period and resurfaces before it lapses, rather than being discovered stale during fieldwork.
Closed on verification, not assertion
Root cause, corrective action, owner and a verification step. Closing only when verification completes is the difference between a finding that is fixed and one that returns next cycle.
Position, not activity
What is covered, what is open, what is overdue and who owns it — per framework, in that framework's terms. A board asks a different question from an assessor, and both should be answerable without assembling a deck.
The evidence request nobody answers
Worth naming, because every compliance function recognises it and few treat it as a solvable problem.
A senior engineer receives a request for the same access review export in February for the internal audit, in April for the ISO surveillance visit, in July for a customer's vendor assessment, and in September for the regulatory submission. Four requests, four formats, one artefact, and one increasingly unresponsive engineer.
By the fourth request the answer is slower, the format is inconsistent, and somebody exports something that is not quite the right thing. That is the point at which evidence quality degrades — not through negligence, but through reasonable people running out of patience with a process that asks them the same question repeatedly.
Frameworks managed separately
Each programme maintains its own evidence list, so the same underlying artefact is requested once per programme rather than once per period.
Declining cooperation
Response times lengthen across the year, and the compliance function reads it as resistance when it is fatigue with a process that never acknowledges what was already provided.
Evidence as a shared object
One artefact, collected once, mapped to every requirement it supports across every framework — so the engineer is asked when the evidence is genuinely due rather than when each programme happens to think of it.
When an enterprise does not need this
Worth saying plainly, because a platform bought before it is needed becomes another system nobody maintains.
- You carry more than two frameworks and the overlap between them is being maintained by hand
- Control owners sit in functions that do not report to compliance
- The same evidence is requested several times a year by different parties
- Findings recur across cycles because closure was asserted rather than verified
- Assembling a board or regulator report takes days of collation
- The person who knows where everything is could leave
- You carry one framework with a stable scope
- The compliance team operates most of the controls itself
- Assessment happens once a year and preparation is manageable
- Evidence volume is small enough that one person holds it in their head
- You are establishing the programme and do not yet know what you need
The honest test is not organisation size. It is whether the coordination cost between functions has exceeded the cost of the work itself. Below that line a spreadsheet is genuinely fine. Above it, more effort from the compliance team does not help — and that is the point at which most organisations start looking.
Starting without a twelve-month project
The enterprises that succeed start narrow. The ones that stall try to model everything before anyone uses it.
- Start with the framework you are assessed against nextNot the most important one — the nearest deadline. Success with one programme earns the cooperation you will need for the rest.
- Build the control library from what you already doYour controls exist. They are in policies, procedures, and people's heads. Capturing them is the foundation, and it is faster than writing new ones.
- Map that framework's requirements to those controlsThis is where you see coverage honestly for the first time, and where the gaps stop being a feeling and become a list.
- Assign owners in the functions that operate themThe uncomfortable step, and the one that determines whether the programme works. A control owned by compliance is a control nobody operates.
- Add the second framework and let the overlap showMost of it maps to controls you have already captured. This is the moment the approach justifies itself to the people who agreed to it reluctantly.
- Move evidence collection onto the platformRequested from owners, reviewed before it counts, with a validity period. This is what ends the four-requests-one-artefact problem.
- Bring findings in from wherever they liveInternal audit, external assessment, customer review. Findings tracked in separate places recur in separate places.
- Then extend to the restOnce two frameworks run properly, adding a third is configuration rather than a project — and by then you have the internal credibility to ask.
One control library shared across the NCA ECC, the PDPL, your ISO certification and your customers' requirements — with each control owned by the person in IT, HR or Procurement who actually operates it, and evidence requested once rather than once per framework.
See it in a demo →Enterprises — FAQs
How is this different from the multi-entity or holding company pages?
Those describe structural problems — several entities with the same obligations, or a portfolio of businesses with different ones. This page describes an internal problem inside a single organisation, where compliance work spans departments that do not report to the compliance function. If you are a group or a portfolio, those pages fit better.
Our controls are owned by IT and HR. Does that work?
It is the only arrangement that does. A control owned by the compliance team is a control nobody operates, because compliance does not run the access review or deliver the training. Assigning ownership to the function that performs the work is uncomfortable to negotiate and it is what makes the difference between a programme and a document.
We run several frameworks. Do we need separate programmes?
No, and that is where most of the value sits. The frameworks overlap substantially — access control appears in all of them — so one implemented control and one approved artefact can satisfy an ECC requirement, an ISO Annex A control and a customer clause simultaneously, with each framework scored in its own terms.
How do we stop asking the same engineer for the same evidence?
By holding evidence as a shared object rather than per programme. One artefact collected once supports every requirement mapped to it, so the request arrives when the evidence is genuinely due rather than once for each framework that happens to need it. This is usually the change control owners notice first.
Can we start with one framework?
You should. Start with whichever assessment is nearest, build the control library from what you already do, and add the second framework once the first works. The overlap becomes visible at that point, which is what justifies the approach internally to people who agreed to it reluctantly.
Is this overkill if we only have one framework?
Possibly. If you carry one framework with a stable scope, the compliance team operates most of the controls itself, and evidence volume is small, a spreadsheet is genuinely fine. The honest test is not organisation size — it is whether coordination cost between functions has exceeded the cost of the work itself.
What about findings that keep coming back?
They recur because closure was asserted rather than verified. A finding needs a root cause, a corrective action, an owner and a verification step — and should close only when verification completes. Fixing the symptom without the root cause is why the same observation appears in a different system six months later.
How long before this is useful?
The first framework mapped against your existing controls is useful immediately, because it tells you your actual coverage rather than your assumed coverage. Enterprises that stall are the ones trying to model everything before anyone uses it.
Our business units do not think compliance applies to them.
That is common and it is where the missing records usually are — the processing activities, the data, the actual risk. Naming an owner in the business unit for the controls that sit there is more effective than escalating, because escalation produces a one-off response and ownership produces a habit.
What if the person who knows everything leaves?
That is one of the clearer signals that a platform is overdue. A programme held in one person's knowledge is a programme with a single point of failure, and the cost of that dependency only becomes visible at the worst possible moment.
See your actual coverage, not your assumed coverage
Start with the framework you are assessed against next, and find out what your existing controls already satisfy.