Regulatory Compliance: Data Security Policy & DAMA CDMP Alignment

Why Regulatory Compliance Belongs in a Database Course

Database administrators do not just install software and tune queries. They are also the technical backstop for an organization's legal obligations. Regulations such as HIPAA, PCI-DSS, and the SOC 2 framework exist because data breaches cause real harm—stolen health records, compromised payment cards, and damaged businesses. Understanding how those frameworks map to specific database controls is a core skill for any working DBA, and it is a central topic in the DAMA CDMP Data Security knowledge area.

DAMA CDMP: The Data Security Knowledge Area

The DAMA Data Management Body of Knowledge (DMBOK2) organizes data management into knowledge areas. Chapter 7, Data Security, describes the activities an organization must perform to protect data: defining security policies, classifying data by sensitivity, managing identities and access, monitoring activity, and auditing compliance. The CDMP exam tests whether candidates understand these activities at a conceptual level and can connect them to real business and technical practice.

Key activities from DMBOK2 Chapter 7 include:

• Data classification — labeling data by sensitivity (e.g., public, internal, confidential, restricted).
• Access entitlement management — granting the least privilege needed for each role.
• Activity monitoring and auditing — logging who accessed or changed data and reviewing those logs.
• Encryption management — protecting data at rest and in transit.
• Compliance management — mapping controls to regulatory requirements and demonstrating that controls work.

Regulatory Frameworks at a Glance

HIPAA Security Rule

The Health Insurance Portability and Accountability Act (HIPAA) requires covered entities and their business associates to protect electronic Protected Health Information (ePHI). The Security Rule groups safeguards into three categories: administrative (policies and training), physical (facility controls), and technical (database-level controls). Technical safeguards relevant to DBAs include access controls, audit controls, integrity controls, and transmission security. HIPAA does not mandate specific technologies—it requires that organizations assess risk and implement reasonable and appropriate measures.

PCI-DSS

The Payment Card Industry Data Security Standard applies to any organization that stores, processes, or transmits cardholder data. Its requirements address network security, access control, encryption, vulnerability management, monitoring, and security policies. From a database perspective the critical concepts are: cardholder data must be encrypted at rest; access to cardholder data must be limited to those with a business need; all access must be logged; and duties must be separated so no single person can both make a change and approve it. The official PCI-DSS documentation is maintained at pcisecuritystandards.org.

SOC 2

Service Organization Control 2 is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It is not a law but a voluntary standard used by technology and cloud-service companies to demonstrate trustworthiness to clients. SOC 2 evaluates five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. At a general level, a SOC 2 audit examines whether the organization has written policies, technical controls that match those policies, and evidence (logs, tickets, screenshots) that the controls actually operate over time.

Mapping Controls to Mechanisms in PostgreSQL

The following table shows how policy requirements translate into PostgreSQL technical mechanisms—the same controls you implemented in earlier lessons:

| Policy Requirement | PostgreSQL Mechanism |

|---|---|

| Encrypt data at rest | pgcrypto extension or filesystem/tablespace-level Transparent Data Encryption (TDE) via EDB or OS tools |

| Encrypt data in transit | SSL/TLS connections enforced in `pg_hba.conf` and `postgresql.conf` (`ssl = on`) |

| Enforce least-privilege access | `GRANT` and `REVOKE` statements; `CREATE ROLE` with limited privileges |

| Separate duties | Distinct roles for DBA, application user, auditor; no single login with both `SUPERUSER` and application access |

| Audit log access and changes | `pgaudit` extension; PostgreSQL logging parameters (`log_connections`, `log_disconnections`, `log_statement`) |

| Authenticate users securely | SCRAM-SHA-256 authentication in `pg_hba.conf`; avoid `trust` except on loopback for testing |

Writing a Security Policy: What Must It Contain?

A database security policy is a written document, approved by management, that states what the organization requires and why. A compliant policy for a retail company handling payment cards should address at minimum:

1. Scope — which systems and data are covered.

2. Data classification — how cardholder data is labeled and handled differently from general business data.

3. Access control — who may access cardholder data tables, how credentials are managed, and how access is reviewed periodically.

4. Encryption — requirements for encrypting stored card data and for using TLS on all connections that carry card data.

5. Audit logging — what events are logged, how long logs are retained, and who reviews them.

6. Separation of duties — no single person can both administer the database and approve their own access changes.

7. Incident response — steps to take when a breach or anomaly is detected.

Each policy statement should name the technical control that enforces it and describe how an auditor would verify compliance—for example, by reviewing the PostgreSQL configuration file, sampling the audit log, or inspecting role membership in `pg_roles`.

Safety and Professional Responsibility

Handling regulated data carries professional and legal responsibility. As a DBA you should never store credentials in plain-text scripts or configuration files, never share superuser passwords, and never disable audit logging to "speed things up" in production. Treat a compliance requirement as a safety requirement: just as lockout/tagout protects workers from physical harm, encryption and access controls protect individuals from identity theft and financial harm. Violating a compliance requirement can expose your employer to fines, litigation, and reputational damage—and can end your own career.