The Data Governance, Access and Privacy Operating Standard: Making Control Usable

People need a safe, usable way to request and work with data. When ownership, access or retention rules are unclear, they may wait, reuse old extracts or create uncontrolled copies. Make the controls part of normal work, with named owners and clear routes for exceptions and quality problems.

This standard helps the CIO, CDO and risk executive establish an operating control system for one bounded data domain or use. It does not replace qualified legal, privacy, security or records authority. It routes data defects to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision, architecture change to The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface and ongoing data-product operation to The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn.

1. The Market Connection Context

The recognisable condition is a leadership meeting delayed by data access, followed by a hurried exception. Nobody can name the accountable data owner; labels such as “confidential” do not specify permitted uses; similar requests receive different answers; retention is inherited from storage defaults; quality failures have no route to the source owner; and access reviews count accounts without confirming whether use remains necessary.

The value path is:

Legitimate decision or service need
→ classified data and accountable ownership
→ usable request and decision path
→ controlled access, retention and quality escalation
→ monitored use, exceptions and revocation
→ accountable decision and service value

Potential consequences include delayed decisions, duplicated work, inappropriate use, customer or employee harm, security exposure, uncontrolled retention, misleading analysis and weak accountability. These effects remain REQUIRES VALIDATION until the organisation traces actual requests, decisions, access, processing, quality incidents, exceptions, retention and outcomes.

The usable control contract

For each data domain or bounded use, record:

• a business owner accountable for meaning, authorised use and value;
• a steward responsible for definitions, quality issue coordination and records;
• technical and security custodians responsible for implementation and monitoring;
• qualified privacy, legal, records and specialist authorities within mandate;
• classification based on content, people, purpose, consequence and contractual or regulatory requirements;
• a request route with required fields, evidence, decision rights, service states and escalation;
• access that is bounded by identity, role, purpose, data, environment, action and expiry;
• retention and disposal rules with authority, trigger, hold, deletion or archive evidence;
• a quality escalation route connected to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision rather than an access workaround;
• exceptions with scope, compensating controls, owner, evidence, expiry and review;
• monitoring that tests use, privilege, exports, exceptions, expiry, quality and control response.

Control dispositions

Use one primary human disposition:

Privacy and security are not labels

The South African Protection of Personal Information Act is an official primary legal source containing conditions and duties relevant to personal-information processing (POPIA Act 4 of 2013, VERIFIED primary source). This guide does not interpret whether a particular activity is lawful or compliant. Named qualified authorities must establish applicable obligations, roles, lawful grounds, safeguards, notices, records, retention and data-subject routes.

NIST’s Privacy Framework describes accountability across executive, process and implementation levels and connects requirements to controls and ongoing reassessment (Using Privacy Framework 1.1, VERIFIED official guidance). It is a voluntary risk framework, not legal authority.

Scope and boundaries

Use the standard for one domain, product, analytical use, operational data service or controlled sharing relationship. It covers authority, inventory, classification, request design, access decisions, implementation, retention, quality escalation, exceptions, monitoring, review and revocation.

The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision owns fitness and remediation of data quality for a named decision use. The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface owns source-to-interface architecture and material movement, transformation or semantic design. The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn owns continuing data-product reliability, incidents, changes and service outcomes. The Data Governance, Access and Privacy Operating Standard: Making Control Usable governs whether and how data may be used and how control decisions remain executable.

Expected outputs are a governance ownership/classification register, access request/decision register, retention/quality/exception register, and monitoring/review/revocation register. They are control artefacts, not proof of compliance, security, privacy, quality or appropriate use.

2. The Leadership vs. Delegation Boundary

The reader recognises that practical governance needs ownership, classification, access pathways, retention, quality escalation, privacy and monitored exceptions embedded in work.

Internal leadership

An internal multidisciplinary team can lead when owners are authorised and available, qualified authorities can decide specialist questions, request and revocation controls are executable, and people can challenge inappropriate use without informal retaliation. Technical administrators must not be forced to infer business purpose or legal authority.

Independent leadership

Independent challenge is justified where powerful requesters bypass controls, ownership is disputed, controls are marked by their designers, legacy access cannot be explained, classification is inconsistent, or one team combines use sponsorship and assurance. A partner may structure evidence and workflow but cannot become the organisation’s privacy, legal, risk or data authority.

Narrow specialists

Use qualified privacy, legal, records, cybersecurity, identity, accessibility, workforce or sector specialists for bounded conclusions. Route data-quality diagnosis to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision, architecture design to The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface and production operation to The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn.

Stop and escalation

Stop or revoke use for absent authority, unknown identity, materially changed purpose, prohibited data movement, expired exception, uncontrolled export, uncontained security or privacy event, quality failure that invalidates the use, or inability to retrieve or dispose of records as required. Escalate business use to the data owner, technical containment to CIO/security, privacy and legal questions to qualified authority, and affected-person consequence to sponsor/risk executive.

Questions for evaluating a governance partner

1. How will requesters understand what evidence and authority are required?
2. Which decisions belong to data owners, custodians and qualified authorities?
3. How does classification change actual access, handling, sharing, retention and monitoring?
4. Which request states and escalation routes prevent silent queues?
5. How are purpose, identity, environment, action and expiry enforced together?
6. How are data-quality failures separated from access denials and routed to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision?
7. How are legal holds, deletion, archive and disposal evidence reconciled?
8. How do exceptions expire and return to standard control?
9. Which monitoring signals trigger review, revocation or incident response?
10. What capability remains internally after the partner leaves?

3. The Step-by-Step Execution Standard

Use the Governance Ownership and Classification Register, Access Request and Decision Register, Retention Quality and Exception Register, and Monitoring Review and Revocation Register.

Step 01: Charter the governed data use

Purpose and decision served Bound the domain, affected people, decision or service use, authorities and permitted dispositions.

Accountable owner Executive sponsor with data owner and risk executive.

Delegated lead and contributors Governance lead; steward, custodian, security, privacy, legal, records, architecture and user representatives contribute.

Preconditions, inputs and access Named business need, systems, current policies, authority, affected populations, contracts and qualified referral routes.

Actions

1. Assign stable charter, domain, use and decision IDs.
2. State purpose, population, consequence, expected value and excluded uses.
3. Name sponsor, owner, steward, custodians, qualified authorities, challenger and evidence custodian.
4. Define evidence threshold, dispositions, escalation and stop authority.
5. Record conflicts, legacy access, third parties and decision date.

Evidence to retain Charter, authority map, use statement, conflict register and evidence plan.

Decision or scoring rule Proceed only when purpose, people, authority and affected data boundary are explicit.

Output and template Charter rows in T01.

Acceptance gate CHARTERED, VALIDATE, CHANGE, REFER, DEFER or STOP.

Leadership checkpoint Sponsor accepts that useful data access and protection are joint outcomes.

Human control point Qualified humans define applicable authority; systems do not infer it.

Failure modes and safeguards Policy scope becomes universal; bind the charter to one domain or use.

Change, stop or escalation condition Stop for unowned purpose or unavailable qualified authority.

Handoff to the next step Send the accepted scope to ownership mapping in Step 02.

Step 02: Assign ownership and decision rights

Purpose and decision served Separate business meaning, use authority, stewardship, custody and specialist mandates.

Accountable owner CDO or CIO with executive sponsor.

Delegated lead and contributors Governance lead; domain leaders, stewards, platform/security custodians and qualified authorities contribute.

Preconditions, inputs and access Charter, organisation mandates, data flows, service ownership and escalation structures.

Actions

1. Assign accountable owner for each domain and material element.
2. Distinguish owner, steward, technical custodian, security custodian and qualified authority.
3. Define who may approve, condition, refer, reject, revoke and grant exceptions.
4. Map delegation limits, alternates, conflicts and escalation.
5. Test decisions with representative requests and absence scenarios.

Evidence to retain RACI/authority record, delegation, decision rehearsal and unresolved ownership disputes.

Decision or scoring rule No material decision or control remains with an unnamed committee or technical default.

Output and template Authority rows in T01.

Acceptance gate OWNED, CONDITION, VALIDATE, ESCALATE or STOP.

Leadership checkpoint Sponsor resolves cross-domain ownership conflicts.

Human control point Named authorities accept mandates and workloads.

Failure modes and safeguards Stewards receive accountability without authority; record actual decisions and escalation.

Change, stop or escalation condition Escalate contested ownership or unavailable decision capacity.

Handoff to the next step Send owned domains to inventory and classification in Step 03.

Step 03: Inventory and classify data by use and consequence

Purpose and decision served Create classifications that drive specific controls rather than decorative labels.

Accountable owner Data owner with risk and qualified authority acceptance.

Delegated lead and contributors Steward; security, privacy, records, architecture and system owners contribute.

Preconditions, inputs and access Owned domain, source/interface inventory, data elements, uses, populations, contracts and applicable requirements.

Actions

1. Inventory material datasets, elements, derived data, copies, interfaces, exports and third parties.
2. Record content, identifiability, sensitivity, purpose, affected people, consequence and contractual constraints.
3. Assign organisation-approved classification with evidence and qualified referrals.
4. Map each class to access, handling, sharing, environment, retention, monitoring and disposal controls.
5. Record unknowns and prohibit favourable inference from missing classification.

Evidence to retain Inventory, classification rationale, control mapping, referrals and gap register.

Decision or scoring rule Classification is accepted only when it changes named control behaviour.

Output and template Classification rows in T01.

Acceptance gate CLASSIFIED, REFER, VALIDATE, RESTRICT or STOP USE.

Leadership checkpoint Data and risk owners accept consequence and control implications.

Human control point Qualified authorities decide specialist classifications and obligations.

Failure modes and safeguards One broad label blocks work or permits too much; classify at decision-fit granularity.

Change, stop or escalation condition Escalate unknown personal, contractual, regulated or high-consequence data.

Handoff to the next step Send classification/control mappings to request design in Step 04.

Step 04: Design the request and decision path

Purpose and decision served Make legitimate access understandable, traceable and timely without bypassing evidence.

Accountable owner Data owner with governance operations owner.

Delegated lead and contributors Workflow designer; requesters, stewards, IAM, security, privacy and service teams contribute.

Preconditions, inputs and access Classification controls, authority map, representative request demand, support capacity and escalation rules.

Actions

1. Define request fields: requester, purpose, data, population, action, environment, recipients, period, evidence and owner.
2. Route by classification, consequence, novelty and qualified-review need.
3. Define states RECEIVED, CLARIFY, REFERRED, DECISION READY, DECIDED, IMPLEMENTED, EXPIRED, REVOKED.
4. Publish decision owners, required evidence, escalation and requester challenge route.
5. Test normal, urgent, rejected, conditional, expired and duplicate requests.

Evidence to retain Request schema, workflow, routing rules, service states, tests and user feedback.

Decision or scoring rule Urgency changes escalation, not mandatory authority or evidence.

Output and template Request rows in T02.

Acceptance gate PATH USABLE, CHANGE, VALIDATE, DEFER or STOP.

Leadership checkpoint Owners accept workflow capacity and escalation.

Human control point Requesters can reach a named human decision and challenge route.

Failure modes and safeguards Forms become queues; expose state, owner, missing evidence and next action.

Change, stop or escalation condition Escalate systematically blocked legitimate uses or uncontrolled informal routes.

Handoff to the next step Send complete requests to Step 05.

Step 05: Decide access within an explicit boundary

Purpose and decision served Make a traceable, use-specific decision that can be implemented and revoked.

Accountable owner Data owner with qualified authorities where required.

Delegated lead and contributors Steward and access analyst; security, privacy, legal, records and system owners contribute.

Preconditions, inputs and access Complete request, classification, authority, quality fitness, controls, recipient and environment evidence.

Actions

1. Verify identity, role, purpose, data scope, action, environment, recipients and expiry.
2. Confirm minimisation and whether a less exposed route meets the need.
3. Refer legal, privacy, security, contractual or records questions to qualified owners.
4. Record conditions, monitoring, quality limits, review and revocation triggers.
5. Choose one permitted disposition and retain rationale and dissent.

Evidence to retain Decision, referrals, conditions, evidence IDs, dissent and expiry.

Decision or scoring rule Role membership alone cannot approve a materially different purpose or action.

Output and template Decision rows in T02.

Acceptance gate APPROVE WITHIN BOUNDARY, APPROVE WITH CONDITIONS, VALIDATE, CHANGE, REFER, DEFER or REJECT.

Leadership checkpoint Material consequential uses are visible to sponsor/risk authority.

Human control point Named authority decides; automated routing may assist but cannot accept risk.

Failure modes and safeguards Prior approval becomes perpetual precedent; bind to current purpose, scope and period.

Change, stop or escalation condition Reject or stop where mandatory authority, quality or control evidence fails.

Handoff to the next step Send accepted decision to implementation in Step 06.

Step 06: Implement access and preserve evidence

Purpose and decision served Ensure technical and procedural access matches the human decision exactly.

Accountable owner Technical custodian with data-owner acceptance.

Delegated lead and contributors IAM/platform administrator; security, data engineering and request owner contribute.

Preconditions, inputs and access Authorised decision ID, identity, resources, permissions, conditions, expiry, monitoring and rollback.

Actions

1. Translate decision boundary into least-privilege role, attribute, row, column, environment and action controls as applicable.
2. Separate approval, provisioning and verification where consequence requires it.
3. Link implementation, configuration, identity and version evidence to the decision.
4. Test permitted, denied, expired, exported and exception paths.
5. Notify requester and owner of boundary, responsibilities, quality limits and revocation route.

Evidence to retain Provisioning record, configuration/version, tests, notifications and verification.

Decision or scoring rule Implemented privilege must be no broader or longer than the accepted decision.

Output and template Implementation rows in T02.

Acceptance gate IMPLEMENTED AND VERIFIED, CORRECT, ROLL BACK, DEFER or STOP.

Leadership checkpoint Material deviations go to data and security owners.

Human control point An independent accountable role verifies consequential access.

Failure modes and safeguards Group inheritance broadens access; inspect effective privilege and downstream copies.

Change, stop or escalation condition Revoke unknown, excessive or unverifiable privilege immediately within authority.

Handoff to the next step Send verified use to retention and lifecycle control in Step 07.

Step 07: Contract retention, holds, disposal and retrieval

Purpose and decision served Keep data and control records only within accepted lifecycle authority and operational need.

Accountable owner Records/data owner with qualified legal and privacy authority.

Delegated lead and contributors Records manager and technical custodian; business, security, privacy and system owners contribute.

Preconditions, inputs and access Classification, purpose, sources, derived copies, applicable schedules, contracts, holds and system capability.

Actions

1. Assign retention trigger, period or event, authority, owner and scope to each record class.
2. Map authoritative record, copies, caches, extracts, backups and derived outputs.
3. Define hold, archive, deletion, anonymisation or disposal paths through qualified authority.
4. Test retrieval, integrity, hold application, expiry, deletion and disposal evidence.
5. Record system limitations and compensating controls without claiming legal sufficiency.

Evidence to retain Retention schedule, copy map, hold record, retrieval/deletion tests and disposal evidence.

Decision or scoring rule Storage default, low cost or technical convenience is not retention authority.

Output and template Retention rows in T03.

Acceptance gate LIFECYCLE CONTROLLED, REFER, VALIDATE, REMEDIATE, RESTRICT or STOP.

Leadership checkpoint Owners accept unresolved system limitations and resources.

Human control point Qualified owners decide holds and applicable retention/disposal requirements.

Failure modes and safeguards Deletion in one system leaves copies; reconcile end-to-end lifecycle evidence.

Change, stop or escalation condition Escalate inability to retrieve, hold, delete or prove disposal where required.

Handoff to the next step Send lifecycle evidence and active use to quality escalation in Step 08.

Step 08: Route quality failures without bypassing control

Purpose and decision served Protect decisions and services when data fitness fails while preserving access authority boundaries.

Accountable owner Data owner and decision/service owner.

Delegated lead and contributors Steward; source owner, analyst, custodian and The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision quality lead contribute.

Preconditions, inputs and access Named use, quality rules, incident or observation, lineage, affected decisions and escalation authority.

Actions

1. Record failed quality/meaning rule, population, period, source, consequence and evidence.
2. Contain affected use through warning, restriction, substitute source, defer or stop.
3. Route diagnosis and remediation to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision with source and use context.
4. Separate permission to access from fitness to use.
5. Record resolution evidence, residual limitation and re-authorisation need.

Evidence to retain Quality escalation, containment, The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision handoff, resolution and affected-decision reconciliation.

Decision or scoring rule Access approval never overrides a failed mandatory quality or meaning gate.

Output and template Quality rows in T03.

Acceptance gate USE WITHIN LIMIT, VALIDATE, REMEDIATE UNDER DATA MATURITY, QUALITY AND LINEAGE ASSESSMENT, RESTRICT, REPLACE or STOP USE.

Leadership checkpoint Decision owners see material quality limitations and affected actions.

Human control point Named owner decides whether current use can continue within limitation.

Failure modes and safeguards Teams create uncontrolled extracts to escape quality problems; keep authority and remediation linked.

Change, stop or escalation condition Stop consequential use when fitness evidence is absent or contradicted.

Handoff to the next step Send unresolved bounded needs to exception governance in Step 09.

Step 09: Govern exceptions as expiring decisions

Purpose and decision served Allow justified bounded deviation without creating silent permanent policy.

Accountable owner Risk/data authority named by exception type.

Delegated lead and contributors Governance lead; requester, steward, security, privacy, records and service owners contribute.

Preconditions, inputs and access Failed or unavailable standard control, business consequence, alternatives, compensating controls and authority.

Actions

1. State exact requirement, reason, scope, people, systems, actions and consequence.
2. Document alternatives considered and why standard control cannot currently apply.
3. Define compensating controls, evidence, owner, expiry, monitoring and closure plan.
4. Obtain specialist and risk acceptance within mandate.
5. Publish exception to implementers and monitor trigger, use and expiry.

Evidence to retain Exception request, alternatives, controls, acceptance, implementation, monitoring and closure.

Decision or scoring rule No exception is approved without an owner, bounded scope, compensating control and expiry/trigger.

Output and template Exception rows in T03.

Acceptance gate APPROVE WITH CONDITIONS, VALIDATE, CHANGE, DEFER, REJECT or REVOKE.

Leadership checkpoint Material or repeated exceptions reach the governance forum.

Human control point Only authorised humans accept residual exposure.

Failure modes and safeguards Renewal by silence; expiry automatically triggers review or revocation workflow.

Change, stop or escalation condition Revoke for expired evidence, failed control or material scope drift.

Handoff to the next step Send active access and exceptions to monitoring in Step 10.

Step 10: Monitor use, privilege and control response

Purpose and decision served Detect whether governed use remains inside accepted purpose, access, lifecycle, quality and exception boundaries.

Accountable owner Governance operations owner with security and data owners.

Delegated lead and contributors Monitoring analyst; IAM, platform, privacy, records, stewards and service owners contribute.

Preconditions, inputs and access Decision IDs, effective access, activity evidence, exports, retention, quality, exceptions, thresholds and response runbooks.

Actions

1. Define signals for privilege, inactivity, unusual use, exports, denied actions, expiry, exceptions, retention and quality.
2. Protect monitoring evidence and minimise unnecessary sensitive content.
3. Map each alert to owner, severity, investigation, containment and decision route.
4. Reconcile activity to approved purpose and effective privilege.
5. Test detection, evidence retrieval, response, revocation and false-positive handling.

Evidence to retain Signal contracts, alert tests, investigations, reconciliations, responses and tuning decisions.

Decision or scoring rule Logging without an owned response is not monitoring control.

Output and template Monitoring rows in T04.

Acceptance gate CONTROL EFFECTIVE, TUNE, INVESTIGATE, REVOKE, ESCALATE or STOP USE.

Leadership checkpoint Material trends and unowned alerts reach data/risk leadership.

Human control point Humans determine misuse, consequence and response; anomaly is not guilt.

Failure modes and safeguards Monitoring becomes surveillance or noise; minimise, test proportionality and tune with qualified oversight.

Change, stop or escalation condition Contain unapproved use, control failure or unprotected monitoring evidence.

Handoff to the next step Send current evidence to review in Step 11.

Step 11: Review access, controls and governance performance

Purpose and decision served Determine whether access remains necessary and whether governance enables responsible use.

Accountable owner CDO/CIO and risk executive.

Delegated lead and contributors Governance evidence lead; owners, stewards, requesters, custodians and qualified authorities contribute.

Preconditions, inputs and access Requests, decisions, access, monitoring, quality issues, exceptions, retention, incidents, user feedback and outcomes.

Actions

1. Review purpose, necessity, effective privilege, use, expiry and owner for material access.
2. Reconcile request demand, decision states, escalations, bypasses and abandoned work.
3. Review quality escalations, retention failures, exceptions, alerts and affected-person consequence.
4. Distinguish control burden caused by poor design from necessary specialist review.
5. Decide retain, change, validate, revoke, redesign, refer or stop.

Evidence to retain Review pack, owner attestations with corroboration, exceptions, dissent, decisions and actions.

Decision or scoring rule Account existence or manager attestation alone does not prove continuing need or appropriate use.

Output and template Review rows in T04.

Acceptance gate RETAIN, CHANGE, VALIDATE, REVOKE, REDESIGN, REFER or STOP.

Leadership checkpoint Leaders accept resources, unresolved risk and control usability changes.

Human control point Data, risk and affected owners decide trade-offs.

Failure modes and safeguards Review becomes checkbox recertification; require purpose, use and evidence.

Change, stop or escalation condition Escalate repeated bypass, ownerless access, expired exceptions or material incidents.

Handoff to the next step Send revocations, changes and handover to Step 12.

Step 12: Revoke, hand over and renew governance

Purpose and decision served Close obsolete authority and institutionalise owned, usable control.

Accountable owner Data owner with governance operations owner.

Delegated lead and contributors Steward and custodians; security, records, privacy, architecture and The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn owners contribute.

Preconditions, inputs and access Review dispositions, active identities, copies, exceptions, open quality issues, retention and service dependencies.

Actions

1. Revoke access, tokens, exports, delegated roles and exception authority as decided.
2. Reconcile copies, records, holds, deletion/disposal and open business actions.
3. Transfer current classifications, decisions, measures, runbooks and owner responsibilities.
4. Route architecture changes to The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface, quality work to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision and operational service ownership to The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn.
5. Re-charter materially changed purpose, population, data, recipient, environment or consequence.

Evidence to retain Revocation proof, copy reconciliation, lifecycle evidence, handover acceptance and routing records.

Decision or scoring rule Closure requires authority, access, copies, exceptions and open consequence to reconcile.

Output and template Revocation and handover rows in T04.

Acceptance gate CLOSED, HANDED TO DECISION INTELLIGENCE OPERATING AND SCALE STANDARD, RETURN TO DATA MATURITY, QUALITY AND LINEAGE ASSESSMENT, RETURN TO MANAGEMENT INTELLIGENCE ARCHITECTURE, RENEW or ESCALATE.

Leadership checkpoint Owners confirm current control and unresolved obligations.

Human control point Named owners accept closure and renewed authority.

Failure modes and safeguards Account removal leaves extracts and decisions; reconcile downstream state.

Change, stop or escalation condition Escalate any unaccounted access, copy, exception, hold or affected action.

Handoff to the next step Continue governed operation through The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn and re-charter material new use.

4. The Evidence & Measurement Checklist

Preflight and authority

• One domain or use has a named sponsor and data owner. Evidence: charter. Owner: sponsor.
• Owner, steward, custodian and qualified-authority decisions are separate. Evidence: authority matrix. Owner: CDO.
• Request, exception, revoke and stop authority is executable. Evidence: mandate. Owner: risk executive.
• The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision, The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface and The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn boundaries are explicit. Evidence: scope record. Owner: CIO.
• Conflicts and legacy informal access are disclosed. Evidence: conflict register. Owner: challenger.

Evidence access and quality

• Material datasets, elements, copies, interfaces and recipients have stable IDs. Evidence: inventory. Owner: steward.
• Classifications retain rationale, scope, authority and control mapping. Evidence: classification register. Owner: data owner.
• Requests preserve purpose, population, action, environment and period. Evidence: request record. Owner: governance lead.
• Access decisions link to effective privilege and version evidence. Evidence: implementation record. Owner: custodian.
• Unknown authority or quality remains REQUIRES VALIDATION. Evidence: gap register. Owner: decision owner.

Method execution

• Request states expose owner, missing evidence and next action. Evidence: workflow test. Owner: operations owner.
• Urgency cannot bypass mandatory authority or evidence. Evidence: escalation test. Owner: risk executive.
• Classification changes access, handling, sharing, retention and monitoring. Evidence: control map. Owner: security owner.
• Quality failures route to The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision without expanding access. Evidence: quality escalation. Owner: data owner.
• Exceptions contain scope, control, owner, evidence and expiry. Evidence: exception register. Owner: governance forum.

Governance, privacy, security and risk

• Qualified owners decide legal, privacy, security, records and regulatory questions. Evidence: referral log. Owner: sponsor.
• Effective privilege matches approved identity, purpose, data, action and expiry. Evidence: access test. Owner: security custodian.
• Monitoring evidence is protected and proportionate. Evidence: monitoring approval. Owner: privacy/security authority.
• Retention, holds, disposal and deletion follow named authority. Evidence: lifecycle register. Owner: records authority.
• Affected-person consequence and remedy routes remain visible. Evidence: risk record. Owner: risk executive.

Deliverables and acceptance

• All four working files use linked stable IDs. Evidence: pack index. Owner: evidence custodian.
• Every classification has an accountable owner and executable controls. Evidence: classification test. Owner: data owner.
• Every access decision is implementable, monitorable and revocable. Evidence: decision test. Owner: CIO.
• Every active exception has current evidence and expiry. Evidence: exception review. Owner: risk owner.
• Closure reconciles access, copies, records and open actions. Evidence: closure register. Owner: governance owner.

Measurement

• Request service, control, quality, outcome and guardrail measures remain separate. Evidence: measure register. Owner: CDO.
• Measures state definition, baseline, source, owner, cadence and response. Evidence: metric contract. Owner: analyst.
• Queue speed cannot offset wrong or unauthorised approval. Evidence: guardrail review. Owner: risk executive.
• Access-review coverage includes purpose and observed use. Evidence: review record. Owner: data owner.
• Outcome attribution records policy, demand and architecture change. Evidence: review pack. Owner: proof owner.

Decision and handover

• Every request and exception receives one explicit disposition. Evidence: decision record. Owner: authority.
• Conditions, dissent and rejected alternatives are retained. Evidence: decision pack. Owner: challenger.
• Owners accept classifications, controls and monitoring on handover. Evidence: acceptance. Owner: CDO.
• Architecture, quality and operation issues route to The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface, The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision or The Decision Intelligence Operating and Scale Standard: Monitor, Explain, Decide, Act and Learn. Evidence: routing record. Owner: CIO.
• Revocation closes effective access and downstream copies. Evidence: reconciliation. Owner: custodian.

Review, change and stop controls

• Purpose, population, data, recipient, environment or action change triggers review. Evidence: trigger register. Owner: data owner.
• Expired decisions and exceptions trigger revoke or renewal. Evidence: expiry workflow. Owner: governance operations.
• Uncontained misuse or control failure triggers containment. Evidence: incident record. Owner: security owner.
• Material quality failure triggers restrict or stop pending The Data Maturity, Quality and Lineage Assessment: Establishing What Can Be Trusted for Which Decision. Evidence: quality decision. Owner: decision owner.
• Ownerless or irretrievable data triggers escalation. Evidence: exception record. Owner: risk executive.

Measurement contracts

Measure A: Ownership and classification coverage

Measure B: Request decision integrity

Measure C: Effective access conformity

Measure D: Quality and exception response

Measure E: Responsible data-use outcome

Measure F: Revocation and lifecycle reconciliation

Evidence classifications used in this guide

• VERIFIED: official external guidance or retained organisational evidence checked for identity, scope and relevance.
• INFERRED: a governance interpretation linked to evidence with uncertainty and alternatives visible.
• PROPOSED: an owner, classification, control, request, retention rule, exception or measure awaiting acceptance.
• REQUIRES VALIDATION: a material authority, quality, privacy, security, lifecycle or use claim that cannot support a decision yet.

Sources and evidence notes

1. South African Department of Justice: Protection of Personal Information Act 4 of 2013 is the official primary statutory text. VERIFIED primary legal source; qualified authority must interpret application.
2. Information Regulator South Africa is the official regulator site for current notices, guidance and forms. VERIFIED official institutional source; this guide does not claim regulator approval.
3. NIST: Using Privacy Framework 1.1 supports accountability, organisational communication, processing-ecosystem roles and ongoing reassessment. VERIFIED official voluntary-framework guidance.
4. NIST Privacy Framework 1.0 provides a common risk-management language for privacy activities and parties. VERIFIED official framework; not legal authority.
5. NIST SP 800-53 Rev. 5 control downloads provides authoritative security and privacy control material including access and audit control families. VERIFIED official source; controls require contextual selection.
6. NIST SP 800-53A Rev. 5 provides official assessment guidance for security and privacy controls. VERIFIED official source.

The operating method, dispositions, files, measurements and visuals are PROPOSED Abrasim methods. They do not establish a lawful basis, compliance, privacy, security, quality or outcome.