Controls, Audit & Compliance

Controls, audit, and compliance are what make shared services trustworthy. Centralising work in shared services concentrates risk: a single shared services organisation, serving many business units, can create control gaps (no one owns the control) or concentration risks (one error affects all). The controls framework — designed for shared services, automated where possible, and evidenced continuously — is what manages this risk and keeps the organisation audit-ready.

The challenge is that controls without automation become a bottleneck: every control a manual check is overhead that slows delivery and erodes the efficiency shared services exists to create. The mature model automates controls (policy-as-code, continuous monitoring) so compliance is a by-product of delivery, not a separate activity. Compliance at scale requires automated controls.

This page covers the controls landscape, segregation of duties, audit evidence, regulatory mapping, control automation, and continuous compliance.

Shared services controls span several domains. Access controls (who can do what, least privilege, joiner-mover-leaver) protect against unauthorised access. Change controls (separation of build and deploy, approval workflows, rollback) protect against unmanaged change. Process controls (SOPs followed, exceptions approved, evidence captured) protect against process failure. Data controls (classification, retention, privacy) protect against data misuse.

Each domain has preventive controls (stop the bad thing happening — access denied, change blocked), detective controls (catch the bad thing that happened — monitoring, reconciliation), and corrective controls (fix the bad thing — remediation, escalation). A balanced controls framework uses all three; relying only on preventive controls misses what slips through, relying only on detective controls is too late for high-impact events.

The shared services context adds concentration risk. A control failure in a shared services organisation affects all its customers, not one — a single access control gap can expose every business unit. This argues for stronger controls in shared services than in the business units it replaced, not weaker. The efficiency of shared services must not come at the cost of control; the controls framework is what ensures it does not.

Segregation of duties (SoD) is the principle that no single person should control an end-to-end process — the person who builds a change should not deploy it; the person who approves access should not grant it; the person who records a transaction should not reconcile it. The principle prevents both error (a single mistake propagates) and fraud (a single person cannot both commit and conceal).

In shared services, SoD is both more important and harder. More important because concentration means a single person's unchecked action affects all customers; harder because centralisation can collapse roles that were separate in business units. The discipline is to design roles and approvals so end-to-end control always requires more than one person, and to monitor for SoD violations (a single person accumulating conflicting access).

SoD conflicts are detected and managed. A role-based access model defines which roles conflict (build and deploy, approve and execute); access requests are checked against the holder's existing roles; conflicts are resolved by design (redesign the roles) or by compensating controls (additional monitoring where the conflict is unavoidable). The SoD matrix — the map of conflicting roles and their resolution — is a core controls artefact.

Audits require evidence: that controls exist, that they operated, and that they caught what they should. Evidence assembled under audit deadline is expensive, incomplete, and unconvincing; evidence captured continuously in the flow of work is cheap, complete, and audit-ready. The discipline is to capture evidence as a by-product of the control, not as a separate activity.

The evidence chain for each control: the control defined (the policy or SOP), the control operating (the log or record), the control effective (the outcome — error caught or passed), and the period coverage (evidence for the full audit period, not a sample). Each link must be available; a missing link (no log of the control operating) fails the audit regardless of whether the control actually ran.

Continuous evidence capture — controls that log their operation automatically — is what makes shared services audit-ready at scale. A manual control produces evidence only when someone documents it; an automated control produces evidence every time it runs. The shift from manual to automated controls is as much about evidence as about efficiency: automated controls are audit-ready by construction.

Shared services operates under multiple regulatory frameworks — SOX (financial controls), GDPR/DP (data privacy), ISO 27001 (information security), industry-specific (HIPAA, PCI-DSS), and more. Each framework requires specific controls; mapping the framework requirements to the shared services controls is what demonstrates compliance and avoids both gaps (a requirement not met) and duplication (the same control documented for multiple frameworks differently).

The mapping is a control-to-requirement matrix: each framework requirement mapped to the control that satisfies it, with the evidence that demonstrates it. The matrix is the single view that shows compliance status across frameworks and identifies where a new requirement needs a new control or where an existing control satisfies a new requirement. Without the matrix, compliance is fragmented by framework; with it, compliance is unified.

The matrix must be maintained. Regulations change, controls change, and the mapping must change with them. A mapping that is not refreshed becomes a false assurance — it shows compliance against the old requirements, not the current. The controls owner maintains the mapping as a living artefact, reviewed at each regulatory change and each audit cycle.

Control automation is what makes controls scale without overhead. A manual control — a person checking a sample of changes — is bounded by the person's time: it samples, it is periodic, and it is overhead. An automated control — policy-as-code checking every change against the policy in the pipeline — is total (every change checked), continuous (every time), and embedded (no separate activity). Automated controls are stronger and cheaper.

The automation applies across control types. Access controls: automated joiner-mover-leaver from HR systems, with access reviews that flag anomalies. Change controls: policy-as-code in the pipeline, blocking non-conformant changes. Process controls: workflow engines that enforce SOPs and capture evidence. Data controls: DLP and classification that apply automatically. Each moves the control from manual to automated, from sampled to total.

The shift to automated controls changes the audit. An audit of automated controls verifies the automation is correct and operating (the policy-as-code is right and runs), rather than sampling instances; once verified, the control's coverage is total by construction. This is far cheaper for both the organisation and the auditor, and far more reassuring — total coverage beats sampled coverage, however diligent the sampler.

Continuous compliance is the mature state: compliance not as a periodic project (the audit scramble) but as a continuous state (controls operating and evidencing all the time). The organisation is audit-ready any day, because the controls are running and the evidence is being captured continuously. The audit becomes a verification of the continuous state, not a reconstruction of the past period.

Continuous compliance requires the foundations: automated controls (manual controls cannot be continuous), continuous evidence capture, the regulatory mapping, and a control-monitoring capability that detects when a control is failing. With these in place, compliance is a by-product of operation, not a separate effort. Without them, compliance is a periodic cost and risk.

The payoff is not just audit efficiency. Continuous compliance detects control failures early — when they happen, not at the next audit — and so reduces the window of exposure. A control that fails silently for six months until the audit is six months of risk; a control that fails and is detected the same day is hours of risk. Continuous compliance is a risk-management capability, not just an audit efficiency.