Data Policies, Standards, and the Data Dictionary

What Is a Data Policy?

A data policy is a formal, written statement that declares how an organization creates, stores, uses, protects, and disposes of its data. Policies set the what and why—they do not usually explain step-by-step procedures. For example, a policy might state: "All personally identifiable information (PII) must be classified as Confidential and encrypted at rest." The supporting procedure document would then explain which encryption algorithm to use and who configures it.

Data policies are a cornerstone of data governance. Without them, different departments apply inconsistent rules, data quality degrades, and the organization faces compliance risk. Common policy categories include data classification, data retention, data access control, and data quality standards.

What Is a Data Standard?

A data standard defines the specific, agreed-upon format, code set, or naming convention that data must follow. Where a policy says "addresses must be stored in a consistent format," the standard says exactly which format—for example, using USPS address formats with a two-letter state abbreviation stored in a CHAR(2) column. Standards make it possible for systems to exchange data reliably and for queries to return meaningful results.

Data standards are maintained by a data steward or a data governance committee. The DAMA Data Management Body of Knowledge (DMBOK) describes data standards as a key output of the Data Governance function and an input to every other data management discipline.

What Is a Data Dictionary?

A data dictionary (sometimes called a business glossary when focused on meaning rather than technical structure) is a centralized reference document that describes every data element in a system. For each column in a database, the dictionary typically records:

• Technical name — the exact column name in the database
• Business definition — plain-language explanation of what the column means
• Data type and length — for example, VARCHAR(100) or INTEGER
• Allowable values — enumerated list or domain rule (e.g., status IN ('ACTIVE','INACTIVE','PENDING'))
• Data owner — the business role or person responsible for data quality in that column
• Sensitivity classification — for example, Public, Internal, Confidential, or Restricted/PII
• Constraints — primary key, foreign key, NOT NULL, UNIQUE

A complete data dictionary bridges the gap between IT and business stakeholders. A developer reading the schema knows a column is called `cust_dob`; the dictionary tells them it is "Customer Date of Birth," classified as PII, owned by the Customer Services Manager, and formatted as ISO 8601 (YYYY-MM-DD).

Auto-Generating a First Draft with PostgreSQL information_schema

PostgreSQL stores metadata about every table, column, and constraint in a system catalog called `information_schema`. You can query it with ordinary SQL. Two especially useful views are:

• `information_schema.columns` — one row per column, including table name, column name, data type, character maximum length, and whether null values are allowed.
• `information_schema.table_constraints` — lists constraints (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK) applied to each table.

Querying these views gives you an instant structural skeleton for your data dictionary. It saves significant time compared to reading every CREATE TABLE statement manually, and it is guaranteed to be current with the actual schema.

```sql

SELECT

c.table_schema,

c.table_name,

c.column_name,

c.data_type,

c.character_maximum_length,

c.is_nullable,

c.column_default

FROM information_schema.columns c

WHERE c.table_schema = 'public'

ORDER BY c.table_name, c.ordinal_position;

```

This query returns columns in their defined order for every table in the `public` schema. Export the result to a spreadsheet (DBeaver CE supports CSV export from any result set) and you have a working first draft.

To add constraint information:

```sql

SELECT

tc.table_name,

tc.constraint_name,

tc.constraint_type,

kcu.column_name

FROM information_schema.table_constraints tc

JOIN information_schema.key_column_usage kcu

ON tc.constraint_name = kcu.constraint_name

AND tc.table_schema = kcu.table_schema

WHERE tc.table_schema = 'public'

ORDER BY tc.table_name, tc.constraint_type;

```

Merge the constraint results into your spreadsheet using the table and column names as keys.

Extending the Dictionary with Business Context

The auto-generated skeleton tells you how data is stored; it says nothing about what the data means or who owns it. You must fill in the business columns manually by consulting subject-matter experts, application documentation, and the governing data policy.

For each column, ask:

1. What real-world fact does this column record?

2. Who in the business is accountable if the data is wrong?

3. What values are valid, and what rules apply?

4. Could this data identify a person or expose a legal liability if leaked?

Sensitivity classification is particularly important. Many organizations use a four-tier scheme: Public, Internal Use, Confidential, and Restricted (which covers regulated data such as PII, HIPAA-covered health information, or payment card data under PCI DSS). Misclassifying a Restricted column as Internal can lead to a data breach or regulatory fine.

Safety and Professional Responsibility

Data governance work carries real professional risk. Querying production metadata on a live system can expose sensitive schema information; always work on the designated training instance unless you have written authorization. Never copy real customer data to a personal device or a spreadsheet stored on an unsecured share—this is a policy violation in virtually every organization and may breach privacy law.

When peer-reviewing a colleague's dictionary, treat any test data that resembles real personal information with the same care as production data. Document access to the training database in the system log if your organization's policy requires it.

Peer Review and Quality Gates

A data dictionary is only useful if it is complete and accurate. A structured peer-review checklist prevents gaps from slipping through. Common checklist items include: every column has a non-blank business definition; no sensitivity classification is left as "Unknown"; every foreign key column references the correct parent table in the dictionary; and all allowable-values fields are filled in for columns with limited domains. The DAMA DMBOK recommends treating data dictionary completeness as a measurable data quality dimension—specifically completeness and consistency—and tracking it over time.