Regulatory Compliance 101: Laws, Requirements & Best Practices 

Published: August 2024. Updated: August 2026. Reviewed by Encryption Consulting’s Compliance Advisory team.

What Is Regulatory Compliance, and Why Does It Matter?

Regulatory compliance is the ability to show, with documentation and controls, that your organization meets the laws, standards, and contractual obligations that apply to the data you handle. It is not a certificate you earn once; it is a state you maintain, because regulators and business partners expect ongoing proof, not a one time claim.

It matters because the cost of getting it wrong keeps climbing. According to IBM’s 2025 Cost of a Data Breach Report, the global average cost of a breach was 4.44 million US dollars, a 9 percent drop from the prior year’s 4.88 million, credited largely to faster detection through AI assisted monitoring. Fines sit on top of that: GDPR penalties can reach 20 million euros or 4 percent of global annual turnover, whichever is higher, and HIPAA violations can carry criminal penalties for willful neglect.

Most of the terms in this space get thrown around loosely, so let’s define them once. GDPR (General Data Protection Regulation) is the European Union’s data protection law. CCPA (California Consumer Privacy Act) and its amendment, CPRA (California Privacy Rights Act), are California’s consumer privacy laws. HIPAA (Health Insurance Portability and Accountability Act) protects health information in the United States. PCI DSS (Payment Card Industry Data Security Standard) protects cardholder data. DORA (Digital Operational Resilience Act) is the European Union’s ICT risk rule for financial entities. FIPS (Federal Information Processing Standards) and NIST (National Institute of Standards and Technology) define the cryptographic and security baselines that many of the above regulations point back to.

This post covers the compliance landscape at a survey level: which laws apply, what they share in common, and how to build one program that satisfies all of them. If you need the line by line detail on a single regulation, we link to the deeper resource in each section instead of repeating it here.

Which Regulations Actually Apply to Your Organization?

The regulations that apply to you are determined by whose data you hold and where you operate, not by your industry label alone. Below is a condensed view of the laws most organizations run into; each links out to a deeper, regulation specific resource rather than repeating the full text here.

General Data Protection Regulation (GDPR)

GDPR applies to any organization that processes the personal data of people in the European Union, regardless of where the organization itself is located. It requires a documented lawful basis for processing, honors data subject rights (access, correction, erasure, portability), and mandates breach notification to supervisory authorities within 72 hours of discovery. Fines run up to 20 million euros or 4 percent of global annual turnover. See our GDPR education center article for the full requirement set.

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA governs protected health information (PHI) in the United States through its Privacy Rule and Security Rule, and requires breach notification to affected individuals and the Department of Health and Human Services without unreasonable delay, and no later than 60 days after discovery. Penalties range from 100 to 50,000 US dollars per violation, capped at 1.5 million US dollars annually per violation category, with criminal penalties possible for willful neglect. A Security Rule update has been proposed by HHS but has not been finalized as of this writing, so treat any specific new deadline as unconfirmed until HHS publishes a final rule. Read more in our HIPAA education center article.

Payment Card Industry Data Security Standard (PCI DSS 4.0.1)

PCI DSS applies to any organization that stores, processes, or transmits cardholder data. Version 4.0.1 is the current baseline, and its future dated requirements, covering items like targeted risk analyses, authenticated internal vulnerability scans, and stronger multi factor authentication, became mandatory on March 31, 2025. Non-compliance can mean fines from card networks, higher transaction fees, or loss of the ability to process card payments. See our PCI DSS education center article for the requirement by requirement breakdown.

California Consumer Privacy Act and Privacy Rights Act (CCPA/CPRA)

CCPA, as amended by CPRA, gives California residents the right to know, delete, correct, and opt out of the sale or sharing of their personal information, and it applies to businesses that cross revenue or data volume thresholds regardless of where the business itself is headquartered. New California Privacy Protection Agency regulations covering automated decision making technology, mandatory cybersecurity audits, and risk assessments took effect on January 1, 2026, so if your compliance program still reflects pre-2026 CCPA rules, it is out of date. Civil penalties run up to 7,500 US dollars per intentional violation. See our CCPA versus GDPR comparison for the detailed side by side.

Digital Operational Resilience Act (DORA)

DORA has applied to banks, insurers, and other EU financial entities and their critical ICT providers since January 17, 2025, requiring ICT risk management frameworks, incident reporting, resilience testing, and oversight of third party technology providers. If DORA applies to you, the cryptography and key management requirements deserve their own deep dive; see our DORA cryptography requirements guide and our full DORA compliance guide.

Federal Information Processing Standards (FIPS) and NIST

FIPS standards, issued by NIST, define the security baseline that U.S. federal agencies and their contractors must meet. FIPS 140-2 is being phased out in favor of FIPS 140-3, the current standard for validating cryptographic modules; if your vendors still cite only FIPS 140-2, ask for their FIPS 140-3 validation status. There is no direct fine for non-compliance, but it can cost you the government contract itself, and it frequently underpins compliance with other regulations that reference FIPS by name.

How Should You Classify Your Data Before You Build Controls?

Classify data into a small number of tiers based on regulatory sensitivity and business impact, then attach every later control, encryption, access, retention, to that tier instead of applying one policy to everything. Most regulations do not name specific classification levels; they expect you to have a repeatable method and to treat higher risk data with proportionally stronger controls.

Tier	Example data	Typical regulatory trigger	Baseline control
Public	Marketing content, published pricing	None	Standard integrity controls only
Internal	Internal reports, non-sensitive employee data	General duty of care	Access limited to employees, basic logging
Confidential	Customer PII, contracts	GDPR, CCPA/CPRA	Encryption at rest and in transit, role based access
Restricted	PHI, cardholder data, cryptographic keys	HIPAA, PCI DSS 4.0.1, DORA	Encryption or tokenization, strict least privilege, continuous monitoring

In practice, this means tagging data at the point of collection or ingestion, not after the fact, and reviewing the tags whenever a new data source or system is added.

Should You Encrypt or Tokenize Sensitive Data?

Use encryption when you need the original value back in bulk or across systems you do not fully control, and use tokenization when you can isolate a specific sensitive field and want to shrink your audit scope. Most mature programs use both, applied to different data types rather than picking one approach for everything.

Factor	Encryption	Tokenization
What it does	Transforms data using a reversible mathematical algorithm and a key	Replaces sensitive data with a non-sensitive substitute value, mapped back through a secure vault
Best for	Data you must use in its original form after retrieval, such as file contents, backups, or database columns read by many applications	Structured fields you rarely need to reveal in full, such as card numbers or government ID numbers
Compliance scope impact	Data usually stays in scope for the regulation, since it is still the original data, only unreadable without the key	Tokenized environments can fall outside PCI DSS scope entirely, since no live cardholder data remains present
Key or vault management burden	Requires a key management strategy, rotation, and encryption governance	Requires a hardened token vault and strict access controls around the detokenization path
Typical use case	Encrypting a HIPAA database of patient records	Tokenizing a payment card field to reduce PCI DSS 4.0.1 audit scope

If you are unsure which approach fits a given data flow, map the flow first, then decide; guessing at the architecture level is the most common reason encryption or tokenization projects run over budget.

What Access Controls Do Regulators Actually Expect?

Regulators expect least privilege access enforced through roles, verified through multi factor authentication, and proven through logs, not just a written policy. GDPR, HIPAA, and PCI DSS 4.0.1 each phrase this differently, but the underlying expectation is the same: only people who need the data to do their job can reach it, and you can show who accessed what and when.

• Role based access control (RBAC): assign permissions to roles, not individuals, so access follows the job function and is easy to audit.
• Multi factor authentication (MFA): require it for any account that can reach confidential or restricted tier data, a baseline PCI DSS 4.0.1 now makes explicit for all access into the cardholder data environment.
• Periodic access reviews: re-certify who has access on a fixed schedule, and remove access automatically when a role changes or a contractor’s engagement ends.
• Audit logging: log every access, change, and permission grant to restricted data, and retain those logs long enough to support an investigation or an auditor’s sample request.

How Do You Govern Data Through Its Entire Lifecycle?

Lifecycle governance means defining, in writing, how long each class of data is kept, when it is deleted, and how a data subject’s request to see, correct, or erase their data gets fulfilled, then automating enough of that process that it does not depend on someone remembering to act. Data minimization, one of the most consistent principles across GDPR, CCPA/CPRA, and HIPAA, only holds up if retention and deletion are enforced systematically.

• Set a documented retention schedule per data class, tied to the legal or business reason the data is held.
• Automate deletion or anonymization once the retention period lapses, rather than relying on manual cleanup.
• Build a repeatable workflow for data subject access, correction, and erasure requests, since GDPR and CPRA both expect a response within a defined window.
• Track data lineage across systems so a deletion request actually reaches every copy, including backups and any downstream analytics environment.

What Does Recovery and Backup Have to Do with Compliance?

Recovery and backup matter to compliance because most regulations, including HIPAA’s Security Rule and DORA’s resilience requirements, treat availability as a security requirement, not just an IT concern. A perfectly encrypted dataset that you cannot restore after ransomware or an outage is still a compliance failure, and in some frameworks, an unrecoverable system is itself a reportable incident.

• Set recovery objectives: define a recovery time objective (RTO), how long you can be down, and a recovery point objective (RPO), how much data loss is acceptable, for every system holding regulated data.
• Use immutable backups: keep at least one backup copy that ransomware or an insider cannot alter or delete, and store keys for encrypted backups separately from the backups themselves.
• Test restores, not just backups: a backup you have never restored from is unverified; schedule real restore tests against your stated RTO and RPO.
• Tie recovery into breach response: your incident response plan should specify when a recovery event also triggers a regulatory notification obligation.

How Do You Continuously Monitor Compliance Instead of Auditing Once a Year?

Continuous monitoring means replacing the once a year audit mindset with always on logging, automated alerting, and scheduled evidence collection, so a control failure is caught in days rather than discovered during next year’s assessment. PCI DSS 4.0.1 pushes this directly, requiring more frequent vulnerability scans and targeted risk analyses; GDPR and HIPAA expect it implicitly through their accountability and ongoing risk assessment provisions.

• Centralize logs from identity, network, and data access systems into a SIEM or equivalent platform so anomalies surface quickly.
• Automate evidence collection, screenshots, configuration exports, access lists, so audit preparation is a query, not a scramble.
• Run scheduled internal reviews between formal audits, and treat any finding the same way you would treat an external auditor’s finding.
• Feed monitoring alerts back into your risk register so recurring issues get fixed at the root cause, not just remediated each time they appear.

What Do Auditors Actually Look For Under Each Regulation?

Auditors look for specific artifacts, not general assurances, and the artifact set differs by regulation even when the underlying control is similar. The table below maps six common regulations to the requirement they emphasize and the evidence an auditor will typically request.

Regulation	Core requirement	What an auditor looks for
GDPR	Lawful basis, data subject rights, 72 hour breach notice	Signed consent or legitimate interest records, data subject request logs, breach notification timeline evidence
HIPAA	Privacy Rule and Security Rule safeguards for PHI	Risk analysis documentation, access logs, signed business associate agreements
PCI DSS 4.0.1	Protect stored and transmitted cardholder data	Network segmentation evidence, encryption and key management records, quarterly vulnerability scan results
CCPA/CPRA	Consumer rights to know, delete, and opt out, plus 2026 ADMT and cybersecurity audit rules	Accurate privacy policy, data inventory, documented opt out mechanism, annual cybersecurity audit report where required
DORA	ICT risk management and incident reporting for EU financial entities	ICT risk register, third party provider register, incident reporting logs, resilience testing results
FIPS 140-3 / NIST	Validated cryptographic modules for federal systems and contractors	CMVP certificate numbers, defined module boundaries, documented key management procedures

How to Build a Compliance Program: 8 Steps

Building a compliance program is a sequence, not a checklist you complete in any order; each step below depends on the one before it.

1. Map your regulatory footprint. List every law that applies based on where your customers, employees, and data live, GDPR for EU data subjects, CCPA/CPRA for California residents, HIPAA for PHI, PCI DSS for card data, DORA for EU financial entities.
2. Classify your data. Tag data as public, internal, confidential, or restricted so every later control is sized to actual risk instead of applied uniformly.
3. Choose encryption or tokenization per data type. Use the decision table above field by field rather than encrypting everything by default.
4. Lock down access with least privilege. Implement role based access control, multi factor authentication, and scheduled access reviews.
5. Set lifecycle rules. Define retention schedules, automated deletion, and data subject request handling so data does not outlive its legal purpose.
6. Build recovery into the plan. Set RTO and RPO targets and test immutable backups, since availability is part of security under most of these regulations.
7. Monitor continuously. Replace the annual audit mindset with always on logging, alerting, and automated evidence collection.
8. Audit, train, and improve. Run internal and external audits, maintain a dedicated compliance function, train employees on a recurring schedule, and route findings back into steps 1 through 7.

What Challenges Should You Expect, and What Is Changing Next?

The biggest practical challenges are keeping up with changing rules, untangling data spread across silos and legacy systems, and balancing strong controls against usability, not the individual regulations themselves.

• Regulatory churn: CCPA’s ADMT, cybersecurity audit, and risk assessment regulations only took effect January 1, 2026, and HIPAA’s Security Rule update remains a proposed, not final, rule as of this writing; whatever program you build has to absorb changes like these without a rebuild.
• Distributed and legacy data: data spread across clouds, regions, and older systems makes consistent classification and encryption harder to enforce, and is one of the most common gaps auditors flag.
• Security versus usability: controls that frustrate employees get worked around; pairing strong authentication with something like single sign-on tends to hold up better than friction alone.
• Resource constraints: smaller organizations often lack in-house expertise for multi-regulation programs, which is where a compliance advisory partner earns its keep.
• What is coming next: expect AI assisted monitoring to keep reducing breach detection times, more jurisdictions to adopt data sovereignty rules, and encryption requirements to start factoring in post-quantum readiness as agencies finalize migration guidance.

Limitations

• This guide is a compliance landscape overview; it does not replace legal advice or a formal gap assessment against your specific regulatory footprint.
• Requirements change: the CCPA regulations on automated decision making technology and cybersecurity audits took effect January 1, 2026, and further rulemaking may still follow, so verify current text before relying on any specific clause.
• The compliance mapping table lists common auditor evidence, not an exhaustive checklist; actual audit scope depends on your assessor, industry, and contract terms.
• Encryption and tokenization reduce risk and can shrink audit scope, but they do not eliminate the underlying legal obligation to protect the data.
• Jurisdiction specific rules, data residency requirements, sector regulators, and state laws beyond California, are not covered here in depth; treat this page as the starting map, not the final territory.

What Would Encryption Consulting Recommend?

Our honest recommendation is to stop treating each regulation as a separate project. Every organization we work with that runs GDPR, HIPAA, PCI DSS, and CCPA/CPRA as five different spreadsheets ends up duplicating controls and missing the gaps between them. The fix is one data classification scheme, one encryption and key management strategy, and one continuous monitoring pipeline, with regulation specific reporting layered on top, not built from scratch for each law.

Our Encryption Advisory Services are built around that view. We run an assessment against a custom framework based on NIST, FIPS 140-3, and PCI DSS to find where your current controls fall short. From there we build an encryption strategy tied to your actual data classification, support implementation of encryption governance and key management, and run independent audits to verify what changed actually holds up. If DORA applies to you specifically, pair this with our DORA cryptography requirements guide.

Conclusion

Regulatory compliance is not a document you file once; it is a program built on data classification, a deliberate encryption or tokenization choice, tight access control, lifecycle governance, tested recovery, and continuous monitoring, mapped against whichever laws actually apply to your organization. Build it in that order and each new regulation becomes an overlay on an existing program instead of a project from scratch.

At Encryption Consulting, we help organizations build exactly that kind of program. Our Encryption Advisory Services provide the assessment, strategy, implementation, and audit support needed to meet GDPR, HIPAA, PCI DSS, CCPA/CPRA, DORA, and FIPS requirements without rebuilding your controls for every new law. Reach out to us at [email protected] to talk through your specific compliance footprint.

Frequently Asked Questions

What is the difference between GDPR and CCPA/CPRA? GDPR is an EU wide regulation that applies to any organization processing the personal data of EU residents and requires an affirmative legal basis before processing begins, while CCPA and its CPRA amendments are California state law, apply based on revenue and data volume thresholds, and are built around consumer opt out and access rights rather than upfront consent.

Do we need separate compliance programs for each regulation we fall under? No. Most organizations run one data protection program with regulation specific overlays; classify your data once, then map each regulation’s requirements, consent, notice periods, encryption, audit frequency, onto that same classification instead of duplicating controls.

Is encrypting our data enough to pass a compliance audit? Rarely on its own. Auditors also expect documented access controls, retention and deletion policies, incident response evidence, and, for frameworks like PCI DSS 4.0.1, proof of key management and network segmentation alongside the encryption itself.

How often should we run a compliance audit? Monitor continuously through automation, schedule a formal internal audit at least annually, and complete an independent external audit on whatever cadence your governing regulation requires; PCI DSS 4.0.1 expects annual assessments for most merchant levels, while GDPR sets no fixed interval but expects ongoing accountability.

What should we do first if we discover we are not compliant? Contain and document the gap immediately, determine whether it triggers a mandatory notification deadline, 72 hours under GDPR, without unreasonable delay and no later than 60 days under HIPAA, then remediate the control and update your risk register so the same gap does not recur.

References

• General Data Protection Regulation (EU) 2016/679, official text: eur-lex.europa.eu
• U.S. Department of Health and Human Services, HIPAA Security Rule: hhs.gov
• PCI Security Standards Council, PCI DSS v4.x Resource Hub: pcisecuritystandards.org
• California Privacy Protection Agency, CCPA regulation updates (ADMT, cybersecurity audits, risk assessments): cppa.ca.gov
• Digital Operational Resilience Act (EU) 2022/2554, official text: eur-lex.europa.eu
• NIST, FIPS 140-3, Security Requirements for Cryptographic Modules: csrc.nist.gov
• IBM, Cost of a Data Breach Report 2025: ibm.com