When Each Regulation Applies

Frameworks are voluntary. Regulations are not. Getting this wrong has legal consequences.

SOC 2, ISO 27001, NIST CSF -- those are frameworks. Your company chooses to adopt them, usually because customers or investors demand it. But PCI DSS, HIPAA, GDPR, and CCPA are different. They're regulatory requirements. If they apply to you, compliance isn't optional. If you ignore them, enforcement actions follow: fines, lawsuits, injunctions, and in extreme cases criminal liability.

The hard part isn't understanding any single regulation. It's figuring out which ones apply to your specific organization, and then dealing with the fact that you often owe obligations to several of them simultaneously.

This lesson walks through the four regulations you'll encounter most often in GRC Engineering, with concrete tests for when each one kicks in.

PCI DSS

PCI DSS applies to any entity that stores, processes, or transmits cardholder data. That's the bright-line test. If credit card numbers, CVVs, or magnetic stripe data flow through your systems at any point, you're in scope.

"Any entity" is broad on purpose. It covers merchants (the company selling goods), service providers (companies that process or store data on behalf of merchants), and payment processors themselves. Size doesn't matter. A two-person startup that stores card numbers in a database is subject to the same standard as JPMorgan Chase.

Key technical requirements

PCI DSS v4.0 organizes its 12 requirements into six goals. The ones that dominate a GRC Engineer's time:

• Network segmentation. Cardholder data must live in an isolated network segment. If your VPC has a flat network where the app server and card database share a subnet with your staging environment, you're non-compliant.
• Encryption. Cardholder data must be encrypted at rest and in transit. TLS 1.2+ for transit. AES-256 or equivalent for storage. Key management has its own sub-requirements.
• Access controls. Only personnel with a business need can access cardholder data. Unique IDs per user. MFA for administrative access to the cardholder data environment.
• Logging and monitoring. All access to cardholder data and network resources in the CDE must be logged. Logs must be reviewed daily. Retention: at least one year, with the last three months immediately available.
• Vulnerability management. Quarterly internal and external vulnerability scans. Annual penetration tests. Critical and high vulnerabilities must be remediated within defined timelines.

Merchant levels

The PCI Security Standards Council defines four merchant levels based on annual transaction volume:

The SAQ vs ROC distinction matters. A ROC requires a Qualified Security Assessor (QSA) -- an independent third party -- to audit your environment. An SAQ is self-reported. Level 1 merchants can't self-assess.

The Stripe question

Here's where scope gets practical. If you use Stripe, Braintree, or a similar payment processor and never let raw card data touch your servers, your PCI scope is minimal. Stripe's checkout widget handles the card number client-side and sends it directly to Stripe's servers. Your backend only ever sees a token.

In that scenario, you likely qualify for SAQ A -- the shortest self-assessment. You still need to complete it. You still need HTTPS. But you don't need network segmentation, encryption of stored card data (because you're not storing any), or the full logging regime.

The mistake GRC Engineers catch: a developer adding a card number field to a form that POSTs to your own API "so we can log it for debugging." Congratulations, you've just dragged your entire infrastructure into full PCI scope.

HIPAA

HIPAA applies to two categories of organizations: covered entities and business associates.

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. If you're a hospital, health insurer, or pharmacy, you're a covered entity.

Business associates are anyone who creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity. This is the category that catches most technology companies. If your SaaS product stores patient appointment data for a clinic, you're a business associate. If your cloud hosting provider runs servers that contain PHI, they're a business associate too. The chain extends to subcontractors -- "business associates of business associates."

What counts as PHI

Protected Health Information is any individually identifiable health information. That includes the obvious (diagnoses, lab results, treatment records) and the less obvious (appointment dates, billing records, health plan beneficiary numbers). PHI is defined by the combination of health data plus an identifier that can link it to a specific person. There are 18 defined identifiers, including name, address, dates, phone numbers, email, SSN, medical record numbers, and biometric identifiers.

De-identified data is not PHI. But the bar for de-identification under HIPAA is high -- either expert determination or removal of all 18 identifier types (the "safe harbor" method).

The Security Rule

The HIPAA Security Rule applies specifically to electronic PHI (ePHI) and requires three categories of safeguards:

• Administrative safeguards. Risk analysis, workforce training, contingency planning, access management policies. A security officer must be designated.
• Physical safeguards. Facility access controls, workstation security, device and media controls. Relevant even in cloud-first environments -- someone has to account for laptops that access ePHI.
• Technical safeguards. Access controls (unique user IDs, emergency access procedures, automatic logoff, encryption), audit controls (logs of who accessed what ePHI and when), integrity controls, and transmission security.

The Security Rule uses "required" and "addressable" implementation specifications. "Addressable" does not mean optional. It means you must implement the specification, or document why it's not reasonable and implement an equivalent alternative. Auditors will ask for that documentation.

Breach notification

HIPAA's breach notification rule is strict: covered entities must notify affected individuals within 60 days of discovering a breach of unsecured PHI. If the breach affects more than 500 individuals, the entity must also notify HHS and prominent media outlets in the affected state. Breaches affecting fewer than 500 individuals are reported to HHS annually.

"Unsecured PHI" means PHI that hasn't been rendered unusable, unreadable, or indecipherable to unauthorized persons. In practice, that means: if the data was properly encrypted with NIST-approved algorithms at the time of the breach, and the encryption keys weren't compromised, notification may not be required.

Business Associate Agreements

If you're a technology company that handles PHI, you need a Business Associate Agreement (BAA) with every covered entity you serve, and with every subcontractor who touches PHI on your behalf. A BAA isn't a nice-to-have. Without one, both the covered entity and the business associate are in violation of HIPAA. Major cloud providers (AWS, GCP, Azure) will sign BAAs, but you must request them -- they don't apply by default.

GDPR

GDPR applies to any organization that processes personal data of individuals in the European Union, regardless of where the organization is based. A startup in Atlanta with no EU offices, no EU employees, and servers in us-east-1 is subject to GDPR the moment an EU resident creates an account.

The jurisdictional reach is what makes GDPR different from older privacy laws. It follows the data subject, not the data controller. If you're processing personal data of people in the EU, GDPR applies.

Key principles

GDPR is built on six lawful bases for processing personal data. You must have at least one of them. The most commonly relied-upon bases are consent (the individual explicitly agreed) and legitimate interest (the processing is necessary for a purpose that doesn't override the individual's rights). Choosing the wrong lawful basis -- or failing to document your choice -- is itself a violation.

Core operational requirements:

• Data minimization. Collect only the personal data you actually need for the stated purpose. "We might use it later" is not a valid justification.
• Right to erasure (Article 17). Individuals can request that you delete their personal data. You must comply unless you have a legal obligation to retain it. This has real engineering implications: your database schema needs to support selective deletion without corrupting referential integrity.
• Data Protection Impact Assessments (DPIAs). Required before any processing that's "likely to result in a high risk" to individuals. Profiling, large-scale processing of special category data, and systematic monitoring of publicly accessible areas all trigger DPIA requirements.
• 72-hour breach notification. You must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. If the breach is likely to result in high risk to individuals, you must also notify the affected individuals "without undue delay."
• Data Protection Officer (DPO). Required if you're a public authority, if your core activities involve large-scale systematic monitoring, or if you process special category data at scale.

Special category data

Article 9 defines "special categories" of personal data that receive extra protection: racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, and data concerning sex life or sexual orientation. Processing these categories requires explicit consent or one of several narrow exceptions. In practice, this means health-tech companies face both HIPAA and GDPR's special category rules.

Enforcement

GDPR fines can reach 4% of annual global turnover or 20 million euros, whichever is higher. Meta was fined 1.2 billion euros in 2023 for data transfers. Amazon was fined 746 million euros in 2021 for advertising targeting. These are not theoretical maximums -- they're actual enforcement actions.

CCPA / CPRA

California's privacy law, originally the CCPA (2020) and amended by the CPRA (effective 2023), applies to for-profit businesses that meet any one of three thresholds:

1. Annual gross revenue exceeding $25 million.
2. Data volume: buys, sells, or shares the personal information of 100,000 or more California consumers, households, or devices annually.
3. Revenue from data: derives 50% or more of annual revenue from selling or sharing consumers' personal information.

You must also do business in California, which functionally means: if California residents can use your product, you're likely "doing business in California."

Key consumer rights

CCPA/CPRA grants California residents specific rights over their personal information:

• Right to know. Consumers can request disclosure of what personal information you've collected, the sources, the business purpose, and the third parties it's been shared with.
• Right to delete. Consumers can request deletion of their personal information. Service providers and contractors must also delete upon instruction from the business.
• Right to opt out of sale or sharing. If you sell or share personal information, you must provide a "Do Not Sell or Share My Personal Information" link. "Sharing" under CPRA includes cross-context behavioral advertising -- which pulls in most ad-tech use cases.
• Right to correct. Added by CPRA. Consumers can request correction of inaccurate personal information.
• Right to limit use of sensitive personal information. CPRA added this category, covering SSN, financial account details, precise geolocation, racial/ethnic origin, contents of communications, genetic data, biometric data, health data, and sex life/orientation.

Enforcement

The California Privacy Protection Agency (CPPA) has rulemaking and enforcement authority. Penalties: up to $2,500 per unintentional violation, $7,500 per intentional violation. The CPRA also created a private right of action for data breaches resulting from a business's failure to implement reasonable security measures.

Mapping applicability

The decision tree below gives you a fast read on which regulations to evaluate for any given organization.

┌───────────────────────┐
                       │  Your organization    │
                       └───────────┬───────────┘
                                   │
            ┌──────────────────────┼──────────────────────┐
            │                      │                      │
            ▼                      ▼                      ▼
 ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────────┐
 │ Store, process,  │   │ Create, receive, │   │ Process personal    │
 │ or transmit      │   │ maintain, or     │   │ data of EU          │
 │ cardholder data? │   │ transmit PHI?    │   │ residents?          │
 └────────┬────────┘   └────────┬────────┘   └──────────┬──────────┘
          │                      │                       │
     Yes ─┤                 Yes ─┤                  Yes ─┤
          ▼                      ▼                       ▼
   ┌──────────┐           ┌──────────┐            ┌──────────┐
   │ PCI DSS  │           │  HIPAA   │            │  GDPR    │
   └──────────┘           └──────────┘            └──────────┘

            ┌──────────────────────────────────┐
            │ Do business in California AND     │
            │ meet revenue/data/sale thresholds?│
            └────────────────┬─────────────────┘
                        Yes ─┤
                             ▼
                      ┌────────────┐
                      │ CCPA/CPRA  │
                      └────────────┘

The GRC Engineer's job

Knowing which regulations apply is table stakes. The GRC Engineering value is in translating overlapping requirements into a unified control set. HIPAA wants audit logs. GDPR wants audit logs. PCI DSS wants audit logs. That doesn't mean three separate logging systems. It means one logging pipeline designed to satisfy all three, with documentation that maps each regulation's specific requirements to the implementation.

This is the work of Phases 2 through 8 of this bootcamp: building identity, infrastructure, data protection, and monitoring systems that satisfy multiple regulatory obligations simultaneously. But it starts here, with knowing what you owe.

What comes next

The next exercise in this module tests your ability to identify which regulations apply to real-world company scenarios. After that, the compliance-frameworks module covers the voluntary standards that sit alongside these regulations: SOC 2, ISO 27001, NIST CSF, and CIS Controls. Understanding the difference between "legally required" (regulations) and "commercially required" (frameworks) is one of the first things that separates a competent GRC Engineer from someone reading a checklist.