Data Privacy & Enterprise Security Requirements: From GDPR to SOC 2

As an FDE, your work lands inside a customer's business — which means you inherit their legal duties (whose data you may hold, how long, under which rules) and their security requirements (how a company proves to auditors it's protecting data). This final tutorial covers the two: data privacy — PII, consent, purpose limitation, and data-protection laws like GDPR — and enterprise security requirements — the compliance frameworks, security reviews, and identity/access standards a real company will hold your integration to.

Table of Contents

• Privacy vs Security: Two Different Jobs
• Personal Data / PII
• Special Categories of Data
• The Privacy Principles
• Purpose and Consent
• Data Minimization
• Retention and Deletion
• Data Privacy in an Integration
• The Data Protection Laws (GDPR, CCPA…)
• Privacy by Design
• Why Enterprises Ask Formal Security Questions
• Compliance Frameworks (SOC 2, ISO 27001, HIPAA)
• The Enterprise Access Standard: SSO / SAML / SCIM
• Security Reviews and Self-Assessments
• What a Security Requirement Sheet Looks Like
• Security Non-negotiables an FDE Owns
• Best Practices

Privacy vs Security: Two Different Jobs

The two words travel together, but they are not the same job:

• Security is technical: keeping data from being leaked, modified, or made unavailable (the CIA triad, Tutorial 1).
• Privacy is regulatory and ethical: controlling how personal data is collected, used, stored, and shared, and doing it lawfully.

Security keeps the vault locked; privacy decides what may go in the vault at all, who decides, and for how long. You can be technically very secure and still be far from private — collecting everything, forever, with no consent.

Personal Data / PII

Personal data (also PII — Personally Identifiable Information) is any data that identifies a real person, directly or indirectly:

• direct: name, email, phone, address, ID number;
• indirect: a username, an IP address, a device id, a cookie — anything that can single an individual out.

For an FDE the golden rule is: the moment your integration touches names, emails, HR, medical, or financial fields, you've entered personal-data territory, and the privacy principles below apply.

Special Categories of Data

Many regulations treat some data as special and much more restricted:

• health and biometric data, racial or ethnic origin,
• political or religious views, sexual orientation,
• (financial data, in several frameworks).

If your integration syncs a customer's HR records, health records, payroll, or medical claims, you're handling special-category data. Expect explicit user consent and far stricter rules than for an ordinary contact name. The acceptable-use bar is higher, and so is the regulator's interest.

The Privacy Principles

A short list of principles recurs across the main data-protection laws (GDPR, CCPA). Honor these and you satisfy most of the world's privacy regimes:

You don't need to memorize clauses. You need to answer, for every field — including the ones you don't obviously need — "why am I collecting this, and how long will I keep it?"

Purpose and Consent

Purpose is the honest reason you collect a piece of data. Consent is the user's explicit, informed agreement where the law requires it (marketing, special-category data). They combine:

• Collect only for a stated purpose.
• Don't quietly expand the purpose later ("we now also use it for ads") without fresh consent.
• Offer a way to withdraw consent and have the data deleted.

Consent is not a checkbox you tick by default; it is granular, informed, and revocable.

Data Minimization

Data minimization means: don't collect what you don't need. If your integration only needs a name and email to send invoices, it does not need the person's salary, their family details, or their history.

Needed:    first name, email, order total
Not needed: date of birth, job history, medical history

The less you hold, the less can leak, the smaller any breach, and the fewer privacy obligations you owe. Minimization is your cheapest security control.

Retention and Deletion

Data should carry a lifetime: a defined "why" and a plan for deletion:

• Decide how long each type is kept (e.g., invoices 7 years for tax, chat logs 90 days, temporary files hours).
• Be deletable on request (a user asks to be erased).
• Automate the deletion rather than trusting someone to remember.

Keeping customer data "just in case, forever," with no policy, is a classic privacy defect that turns an ordinary request into a compliance failure.

Data Privacy in an Integration

Apply privacy at the wiring level of every customer integration:

• Least data, least privilege: only the fields and the DB access you truly need (Tutorials 3 and 7).
• Encrypt PII at rest and in transit (Tutorial 4).
• Record a purpose + consent per flow; let users review and delete.
• Document what data you process, and for how long — you'll need it for the security review and for the customer's privacy team.

When your integration pulls from a customer's system, ask for just the fields you need — "the contact fields we need" — not a full export you then hold.

Basic Data Privacy Laws: GDPR, CCPA, and others

Several regimes exist; which applies depends on where data subjects live and where you operate:

You don't need to be a lawyer to be an FDE, but you do need to know the rules most relevant to your customer's data — usually GDPR plus your home region's law — and to ship the consent, access, and deletion hooks nearly all of them require.

Privacy by Design

Privacy by design means building privacy in, not retrofitting it after lunch. Practically: minimize what the UI/API requests, define retention, support deletion, log access to special data. It's the principle regulators most want to see written down in your design, not promised in a slide.

Why Enterprises Ask Formal Security Questions

When a customer's security team reviews your product, they ask structured questions — not out of curiosity but to assess you before handing over their data. Expect vendor questionnaires covering access control, encryption, data retention, SSO, and incident response. As an FDE you should know these answers about your own product and be able to point to the evidence, because the door to the customer often runs through security.

Compliance Frameworks: SOC 2, ISO 27001, HIPAA

Frameworks are standard ways to prove you meet security and privacy requirements:

The practical point: which frameworks your company attests to, and where the control evidence lives, are the answers a customer's security team will scale from a demo to a vendor call.

The Enterprise Access Standard: SSO / SAML / SCIM

Enterprises expect you to plug into their identity system, not to create your own set of users and passwords:

• SSO / SAML (or OIDC) — let employees sign in to your product with their corporate identity (Okta, Microsoft Entra), so you never store corporate passwords.
• SCIM — provision and deprovision users from the identity provider so access drops off automatically when someone leaves.

Security meaning: you inherit their access-control decisions (Tutorial 3) — instantly revoking on off-boarding — and you gain trust partly because you don't hold credentials.

Security Reviews and Self-Assessment

Every enterprise expects a review of your integration, before and after it goes in:

• Before: a vendor questionnaire (access, encryption, SSO, retention, incident process), review of planned access scope.
• During: least privilege, minimal scope, logging who did what.
• After an incident: notification within a defined timeline and an owner.

Whatever the form, the substance is this series' controls: least privilege, secrets, encryption, access control, validation, and a documented incident plan. A security review is really a test of how many of those you built.

What a Security Requirement Sheet Looks Like

A typical enterprise "security requirements" page asks the same handful of questions. Keep a fill-in template in your back pocket:

1. Where does the data live? (region — EU / US / …)
2. How is data encrypted — at rest and in transit?
3. Who can access it, and how is access controlled? (least privilege, SSO)
4. How long is data retained, and how is it deleted?
5. Do you hold certifications / attestations? (SOC 2, ISO 27001 …)
6. How do you detect and respond to a breach?

These aren't abstract; they map one-to-one to chapters of this tutorial. If you can answer all six coherently, your enterprise security readiness moves from "demo" to "production."

Security Non-negotiables: The Minimum an FDE Ships

These aren't optional, whatever your org chart:

• No hardcoded secrets (Tutorial 2).
• DB least-privilege and parameterized queries (Tutorials 4 and 6).
• Auth every route + access control + ownership (Tutorials 1 and 3).
• Validate input, encode output (Tutorial 6).
• SSO/scopes, and least-privilege tokens (Tutorial 5).
• PII/privacy defaults: minimize data, define retention, build a delete path (this chapter).

Before your integration touches a real customer, these are the things you must already be able to do, because they are also the customer's security questionnaire.

Best Practices

• Split security (technical) from privacy (legal/ethical) — and do both.
• Minimize data — only the fields, and only for the length you truly need.
• Retention → deletion — a defined lifetime, user deletion, automated removal.
• Consent is opt-in, informed, revocable — never a pre-ticked default.
• Be ready for the review — know your framework and your evidence.
• Support SSO/SCIM — don't hold corporate passwords.
• Log the audit — who saw what, so privacy and incident calls have answers.