Data Governance Quick-Start 2.3C.3-3

Data governance is encoded objective law applied to information: deciding what data you hold, who can see it, under what conditions, and what happens to it when it is no longer needed. When data governance is weak, institutions leak personal information, enable discrimination, create liability, and violate the privacy commitments that privacy by design (1.2.4) requires. When it is strong, data becomes a trusted asset governed by the same structural discipline as any other institutional commitment.

This sidebar provides scaffolding for rolling out data governance as enforced protocol in ninety days.

The Three Principles

Data Minimization

Collect only data necessary for a stated purpose. Document the purpose. If the purpose changes, the data collection changes.

For each data type your institution holds, document:

Table 2.3C.3-2 — Data Inventory Template

Minimum fields for cataloging each data type the institution holds

For each data type, ask: if we deleted this data today, would our operations break? If yes, we need it. If no, we should delete it.

Build an auto-purge system. Data is deleted on schedule unless manually extended with documented justification. If you do not automate purge, data accumulates and the institution gradually moves from "collect what we need" to "keep everything."

Least-Privilege Access

Access to data is granted only for the specific work someone does, for the specific time they need it, with specific restrictions on what they can do with it.

Implement a data access request workflow: person states what data types they need, for what reason, for what time period. Data owner reviews whether the need is justified. If approved, the system grants access at minimum necessary scope for the stated period. Access automatically expires on end date. Extension requires a new request — forcing periodic re-justification.

Access levels: read-only (can see but not modify, export, or use in other systems), export (can download for analysis with restrictions), modify (can change the data — rare, usually only data owner), admin (can change access rules — only data owner and security team).

Role-based access control enforces these levels at the system level. Track every access: who accessed what, when, from which system. Quarterly audit: does access match stated need? If not, remove it.

Selective Disclosure

When sharing data outside the institution — to a vendor, partner, or regulatory body — disclose only the minimum needed for the stated purpose.

For each external data sharing agreement, document:

Table 2.3C.3-3 — External Data Sharing Register

Minimum fields for each external data sharing arrangement

Before sharing, ask: what is the minimum data needed for this purpose? If the external party asks for more, ask again: can you achieve your goal without it? Data sharing agreements are legally binding. Technically, use export controls that send only the agreed-upon fields.

The Data Map

Before you can implement governance, you need to know what data you have. Build a data map.

Step 1: List all systems that hold customer, employee, or sensitive data.

Step 2: For each system, list what data it holds, the source, the age of the oldest record, and whether backups or copies exist.

Step 3: For each data type, ask: do we need it? Old archives from years past? Probably not — delete (unless legally required to hold).

Step 4: For each data type you need, define access rules: who can see it, in what mode, for what purpose.

Step 5: Define retention and purge schedules.

Step 6: Identify the data owner for each type — one person accountable for approving access requests, reviewing quarterly access, and ensuring retention and purge happen. Not "IT." Typically the functional leader (VP of customer success, CFO, etc.). IT implements the controls; the data owner decides the policy.

Privacy Impact Assessment

Before deploying any new system or process that handles data, conduct a privacy impact assessment: what data is being collected, why, who will access it, how long it will be kept, what could go wrong if the data is breached or misused, how to minimize the harm, and whether the benefit justifies the risk. If the benefit does not justify the risk, do not collect the data.

Ninety-Day Implementation

Weeks 1–2 (data inventory): List all systems holding sensitive data. For each, list data types. Identify data owner for each type.

Weeks 3–4 (access audit): For each data type, list who currently has access. For each person, ask: do they need this access for their job? Remove unjustified access.

Weeks 5–8 (access controls): Implement role-based access control or policy-based access if system-level enforcement is not yet available. Set up the access request workflow. Test the cycle: can someone request access, is it reviewed, is it granted with limits?

Weeks 9–10 (retention and purge): For each data type, define the retention period. Build auto-purge or manual purge with accountability. Test on non-critical data.

Weeks 11–12 (audit and review): Run the first access audit: who has access to what, is it justified? Run privacy impact assessments on new systems planned for next quarter. Report to leadership: what data the organization holds, who can see it, how it is protected.

This is not perfect governance. It is a start — and it gives the organization a structural baseline that the restraint principle (2.3C.2) can govern going forward.

Integration Points

• Enforce-in-code flow (2.3C.3-1): Data access decisions are high-stakes and constant-frequency. Most should be hard-coded via role-based access control.
• Under AI conditions (2.3C.3-2): If AI systems are used for any organizational decision, data governance rules apply to training data and operational data.
• Organization evidence pack (2.3C.4-3): The data inventory, access rules, retention schedule, and privacy impact assessments are part of the evidence that the institution is managing data responsibly.