SOC 2, HIPAA & GDPR: What They Mean for PDF Processing
Ask a developer and a compliance officer what "compliant PDF processing" means, and you'll often get two different answers. The developer is thinking about libraries, file formats, and performance. The compliance officer is thinking about frameworks, audits, and risk. Both are right, and neither can finish the job alone.
This guide gives you a shared vocabulary. It explains what three of the most common frameworks (SOC 2, HIPAA, and GDPR) actually require, and how each one translates into decisions about how your software stores, processes, and redacts PDFs.
A note on terms: None of these frameworks mention PDFs by name. They govern data and systems. But PDFs are where a great deal of regulated data lives, so the principles apply directly to how you handle them.
The short version
| SOC 2 | HIPAA | GDPR | |
|---|---|---|---|
| What it is | An auditing framework (from the AICPA) for service organizations | A U.S. law protecting health information | An EU regulation protecting personal data |
| Who it applies to | Any organization that chooses to be audited, often because customers demand it | Covered entities and their business associates | Any organization handling personal data of people in the EU, wherever it's based |
| What it protects | Customer data, measured against defined trust criteria | Protected health information (PHI) | Personal data |
| How you "comply" | An independent auditor issues an attestation report | You meet the law's requirements; there's no official certification | You meet the regulation's requirements; regulators can fine for violations |
| Key PDF-related concern | Proving your controls work over time | Safeguarding PHI in records, claims, and forms | Lawful handling, minimization, and deletion of personal data |
SOC 2: proving your controls work
SOC 2 isn't a law. It's a framework for demonstrating that a service organization manages customer data responsibly. An independent auditor evaluates controls against the AICPA's Trust Services Criteria: security (always included), plus optionally availability, processing integrity, confidentiality, and privacy.
Two things are worth understanding:
- Type 1 vs. Type 2. A Type 1 report assesses whether controls are designed appropriately at a single point in time. A Type 2 report assesses whether they operated effectively over a period, typically several months. Enterprise security teams tend to ask for Type 2 because it shows sustained practice, not a snapshot.
- It's an attestation, not a certification. People often say "SOC 2 certified," but what exists is an auditor's report. Security reviewers will usually ask to read it.
What it means for PDF processing:
- Access to documents is restricted, logged, and reviewed.
- Changes to systems that process documents follow a controlled process.
- Confidential data is protected in transit and at rest.
- You have monitoring and incident response that covers the systems handling documents.
- Vendors in your chain, including the PDF library or service you build on, are evaluated and monitored.
That last point is the one development teams miss. If your product has a SOC 2 report, your auditor will ask about the components inside it. A vendor with its own attestation makes that conversation easier.
HIPAA: protecting health information
HIPAA applies to covered entities (such as providers, health plans, and clearinghouses) and to business associates, the vendors and partners that handle PHI on their behalf. If your software processes patient records, claims, referrals, lab results, or intake forms, you may be a business associate even if you never think of yourself as a healthcare company.
The Security Rule requires administrative, physical, and technical safeguards for electronic PHI. The Privacy Rule governs how PHI may be used and disclosed. The Breach Notification Rule sets obligations when something goes wrong.
There is no official "HIPAA certification" for software. Vendors can support HIPAA compliance, but compliance depends on how the product is deployed and operated.
What it means for PDF processing:
- Business associate agreements. If a third party touches PDFs containing PHI, you generally need a BAA with them. This is one reason cloud-based PDF APIs get extra scrutiny.
- Access controls and audit trails. You should be able to show who accessed which records and when.
- Integrity. Documents shouldn't be altered improperly, which matters for workflows like signing, flattening, and conversion.
- Minimum necessary. Share only the PHI needed for a task. Redaction is the PDF-level tool for this, and it only counts if it permanently removes the underlying data.
- Transmission and storage security. Encryption and secure handling of temporary files are standard expectations.
GDPR: personal data and individual rights
The GDPR applies whenever you process personal data of people in the EU, regardless of where your company is located. Its scope is broad: names, email addresses, ID numbers, and any information that can identify a person all count, and PDFs such as invoices, HR files, and application forms are full of them.
Several principles bear directly on document handling:
- Data minimization and storage limitation. Keep only what you need, for only as long as you need it.
- Integrity and confidentiality. Process data securely, with appropriate technical and organizational measures.
- Processor obligations. If a vendor processes personal data on your behalf, you need a data processing agreement, and you remain accountable for how they handle it.
- International transfers. Moving personal data outside the EU is restricted and requires a valid legal mechanism.
- Individual rights. People can request access to their data and, in many cases, its erasure.
- Breach notification. Certain breaches must be reported to the supervisory authority within 72 hours of becoming aware.
What it means for PDF processing:
- Know where documents are processed. Sending PDFs to a service hosted outside the EU can trigger transfer requirements.
- Make sure deletion is real: originals, derived copies, extracted text, thumbnails, search indexes, and backups.
- Be able to find every document that contains a given person's data. Searchable text extraction helps here, but only if you control where that extraction happens.
- Treat metadata as personal data. Author names and revision history can identify individuals.
The penalties are significant: GDPR fines can reach up to €20 million or 4% of global annual turnover, whichever is higher.
Where the three overlap
Despite different origins, the three frameworks converge on a handful of practical questions about any system that handles PDFs:
- Where does the data go? Deployment model and data location come up in all three. Processing on infrastructure you control simplifies every answer.
- Who can touch it? Least-privilege access and audit logging appear in SOC 2 controls, HIPAA's technical safeguards, and GDPR's security requirements.
- Who else sees it? Third parties that process documents need contractual coverage and ongoing oversight under each framework.
- Is it protected in transit and at rest? Encryption is a baseline expectation across the board.
- Can you remove or limit it? Redaction, retention limits, and deletion support HIPAA's minimum necessary standard and GDPR's minimization and erasure principles, and they back up the confidentiality commitments SOC 2 auditors test.
- Can you prove it? Logs, policies, and evidence are what turn good practice into audit-ready compliance.
Wondering how easily redaction can go wrong? Read our guide, PDF Redaction Fails and How to Avoid Them.
A practical way to start
If you're a developer, bring these questions to your compliance team. If you're in compliance, bring them to engineering:
- Which of our systems open, convert, redact, or extract data from PDFs?
- Is that processing done on our infrastructure or sent to someone else's?
- Which regulations apply to the documents flowing through it?
- What do our vendors' attestations and agreements actually say?
- If we had to prove deletion or redaction tomorrow, could we?
Most organizations discover that the answers live in different people's heads. Writing them down is often the most valuable step.
Vendor attestations as one input
When you choose a PDF SDK or service, the vendor's security posture becomes part of yours. A current SOC 2 Type 2 report, a clear deployment model, and a responsive security process don't make you compliant, but they reduce what you have to prove on your own and shorten security reviews. Treat them as inputs to your evaluation alongside functionality, performance, and support.
Datalogics is SOC 2 Type 2 compliant and our pdfRest API Toolkit Container platform is GDPR and HIPAA compliant. We work closely with engineering and compliance teams at large organizations to match PDF infrastructure to their regulatory requirements. If you're mapping those requirements to your architecture, we can walk you through the process.
Contact us if you'd like to discuss your project, or for more technical questions, schedule a meeting with a software engineer.
This article is general information, not legal advice. Compliance obligations depend on your industry, location, and contracts, so confirm specifics with qualified legal and compliance professionals.