PDF Security Checklist 2026 (Compliance)

A compliance officer at a mid-sized European company is preparing for an ISO 27001 surveillance audit. The auditor has asked for the Statement of Applicability, the risk register, and a list of all processors with active Data Processing Agreements. The compliance officer has 47 documented processors in the ROPA, all with DPAs on file.

The auditor walks through the offices the next morning. He asks the receptionist what she uses to combine PDFs for the weekly board pack. He asks the sales team how they redact pricing details from contracts before sending them to references. He asks the HR specialist how she compresses scanned ID documents for the right-to-work file. He asks the marketing director how she converts InDesign output to compressed PDF for the newsletter.

Across those four conversations, he documents seven different online PDF tools in active daily use. None of them are in the ROPA. None have DPAs on file. None have been reviewed by the DPO. Two of them are processed in non-EU jurisdictions with no documented SCCs. One has had a publicly disclosed data breach in the last 18 months. The other five are reputable companies, but the documentation gap is the audit finding, not the vendor’s actual security posture.

The compliance officer has a clean audit on paper and a substantial gap in reality. This is the most common pattern auditors find, in every framework, in every industry. PDF tools are the canonical shadow-IT category — small, daily, individually low-stakes, collectively the biggest single category of un-cataloged processing activity in most organizations.

This guide is the checklist that closes that gap. It is designed to be canonical — usable as the basis for an internal policy, citable in an audit response, downloadable as a working document, and aligned with the major regulatory frameworks that actually apply to business PDF handling in 2026.

Frameworks covered: GDPR (EU + UK), HIPAA (US healthcare), Indonesia UU PDP No. 27/2022, ISO/IEC 27001:2022 Annex A, with relevant references to FTC Safeguards Rule, Brazil LGPD, California CPRA, and Switzerland’s revised FADP.

Format: ten thematic sections, 50+ specific checklist items, each with a one-paragraph explanation grounded in the relevant regulatory citation. Sections are designed to be used independently — pick the ones that apply to your context.

Download as PDF or DOCX: this checklist is itself a long-form document that benefits from a portable copy. Use a PDF tool to export this page as a printable working document for your team. Most teams print the relevant sections and use them as a working checklist during vendor reviews. The longer-form sections (3, 4, 9) translate especially well to a DOCX working document for collaborative editing.

---

Section 1: Document Classification (10 items)

Before any tool decision, classify the documents your organization handles. The same regulation may apply differently to different document categories, and the right tool depends on the category.

1.1. Maintain a written document classification scheme

Establish at least three categories: Public, Internal/Confidential, and Restricted (containing personal data, health information, financial details, or material non-public information). Some organizations use four-tier schemes (Public, Internal, Confidential, Restricted) for finer control. The scheme should be in your information security policy and reviewed annually. Reference: ISO 27001:2022 Annex A.5.12 (Classification of information), GDPR Article 5(1)(f) (integrity and confidentiality).

1.2. Map each business document type to a classification level

Resumes, employment contracts, performance reviews, payroll → typically Restricted. Marketing brochures, public press releases, published case studies → Public. Internal policies, organizational charts not containing personal data → Internal. This mapping should be reviewed annually and after any major business process change.

1.3. Identify special-category and sensitive data within PDFs

Under GDPR Article 9, special categories include racial/ethnic origin, political opinions, religious beliefs, trade-union membership, genetic data, biometric data, health data, sex life, and sexual orientation. Under HIPAA, all PHI is protected. Under UU PDP Article 4, sensitive personal data has elevated requirements. PDFs containing any of these need extra controls regardless of their primary classification.

1.4. Distinguish controller vs processor roles per document type

Under GDPR Article 4, the controller determines the purposes and means of processing; the processor processes on behalf of the controller. For HR documents your organization is typically the controller. For documents your organization processes on behalf of a client, you may be the processor and the obligations flow upward. Document the role for each major document category.

1.5. Catalog where each document category lives

For each restricted-category document type, document the systems involved: source (e.g., applicant via email), processing (e.g., PDF merge, ATS upload), storage (e.g., HRIS), backup, and archive. This catalog is the foundation of GDPR Article 30 ROPA, HIPAA risk analysis, and ISO 27001 asset inventory.

1.6. Identify documents subject to retention legal requirements

Tax records (typically 7-10 years), employment files (5-7 years post-termination, varies by jurisdiction), medical records (state-specific, often 6-30 years for adults and longer for minors), financial statements (varies by jurisdiction), and legal hold material (until released) all have minimum retention periods. PDF handling must support these.

1.7. Identify documents subject to right-of-erasure requests

Under GDPR Article 17 and CCPA/CPRA, data subjects have the right to deletion in many circumstances. Document which PDF storage locations can actually support targeted deletion (vs immutable backups) — this becomes a compliance gap if not addressed in advance.

1.8. Document cross-border data exposure per document category

If documents containing EU personal data are processed by a non-EU vendor, GDPR Chapter V applies — adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or other transfer mechanism is required. Map this exposure per document category to identify priority for SCC review.

1.9. Identify documents subject to specific industry regulations

PCI-DSS for payment card data, FERPA for educational records (US), GLBA for financial institution customer data (US), FCA rules for UK financial services, KYC/AML for regulated industries. Layer these onto the GDPR/HIPAA/UU PDP framework as applicable.

1.10. Review classification annually and after business changes

Mergers, new product lines, geographic expansion, new vendor categories — all trigger re-classification. Date and version-control the classification scheme; auditors will check that it’s current.

---

Section 2: Vendor Selection (10 items)

Once classification is in place, vendor selection follows. The threshold question is whether you need a vendor at all for a given workflow.

2.1. Prefer architecturally simpler workflows

For confidential documents, in-browser PDF tools (where the file is processed locally on the user’s device via WebAssembly) eliminate the vendor processing relationship entirely. There is no DPA to negotiate, no sub-processor list to monitor, no SCC chain to maintain — because no vendor receives the data. This is the simplest answer to GDPR Article 28 and HIPAA 45 CFR 164.504(e) for routine work.

2.2. Require a Data Processing Agreement (or BAA) before any restricted-data processing

For any vendor that will process personal data, GDPR Article 28(3) requires a written contract specifying the subject matter, duration, nature, purpose, categories of data, controller obligations, and the specific processor obligations. HIPAA 45 CFR 164.504(e) requires a Business Associate Agreement. Without these, the processing is not lawful — regardless of the vendor’s actual security.

2.3. Verify the vendor’s certifications are current and in scope

SOC 2 Type 2, ISO 27001, HITRUST, FedRAMP, PCI-DSS — verify the actual certificate or attestation letter, not just marketing claims. Check the scope: a SOC 2 covering only one product may not cover the product you’re using. Certifications expire; verify the current date.

2.4. Check sub-processor transparency

GDPR Article 28(2) requires the controller’s prior authorization for sub-processors. Reputable vendors maintain a public sub-processor list and notify of changes. If a vendor cannot tell you who they use to process your data, this is a gap.

2.5. Review the vendor’s documented breach history

Check the vendor’s security disclosures, UpGuard or Nudge Security profiles, state attorney general breach archives (US), and ICO breach reports (UK). Absence of a breach is not a guarantee; a pattern of breaches is a warning.

2.6. Confirm data residency options

For EU personal data, EU data residency simplifies the cross-border analysis substantially. Confirm the vendor offers EU-only processing with EU-only sub-processors if your risk tolerance requires it. Same considerations for UK Data Protection Act, Swiss FADP, UU PDP (Indonesia data residency expectations).

2.7. Document the lawful basis for the vendor’s processing

Under GDPR Article 6, every processing activity needs a documented lawful basis. The vendor’s processing inherits the controller’s lawful basis (typically legitimate interest, contract necessity, or legal obligation for B2B vendors). Document this in the ROPA.

2.8. Confirm vendor breach-notification obligations in the DPA

The DPA should require the vendor to notify the controller “without undue delay” — practically, within hours — so the controller can meet the GDPR Article 33 72-hour notification deadline. HIPAA requires Business Associates to notify covered entities within 60 days for most breaches.

2.9. Verify vendor exit terms

How do you get your data out if you cancel the contract? Are there cancellation fees? Can you export in a format the next vendor can ingest? GDPR Article 28(3)(g) requires that the processor return or delete personal data at the end of the contract.

2.10. Maintain a vendor risk register

Beyond the ROPA, maintain a separate vendor risk register that tracks: vendor name, service, classification of data processed, DPA/BAA status, last review date, breach history, certifications, sub-processors, and risk rating. Review at least annually.

---

Section 3: Encryption and Retention (8 items)

Encryption and retention are the most-tested controls in compliance audits. The standards are well-defined, and gaps here are well-publicized.

3.1. Encrypt PDFs containing personal data at rest

AES-256 password protection is the minimum baseline in 2026. For shared file systems, full-disk encryption plus file-level encryption is preferable. Reference: GDPR Article 32(1)(a), HIPAA 45 CFR 164.312(a)(2)(iv), ISO 27001:2022 Annex A.8.24 (Cryptography).

3.2. Encrypt PDFs containing personal data in transit

TLS 1.2 or 1.3 for all transmissions. Email is not encrypted in transit between most providers; do not send personal-data PDFs as plain email attachments. Use encrypted file-share, encrypted email (S/MIME or end-to-end encrypted services), or transmission within an authenticated cloud platform.

3.3. Document the key management practice

Where are the encryption keys stored? Who can access them? How are they rotated? Cloud-managed keys (AWS KMS, Azure Key Vault, GCP KMS) or HSM-backed customer-managed keys are typical patterns. The key management is itself part of the security posture — encryption with poorly-managed keys is encryption in name only.

3.4. Define retention periods per document category

Each restricted document category needs a documented retention period aligned with legal obligation (tax law, employment law, medical record law) and business necessity. Default-keeping-everything is a GDPR Article 5(1)(e) violation.

3.5. Automate retention enforcement where possible

Manual deletion of expired records does not happen reliably. Use systems that automatically delete or archive based on retention policy. For PDF tools, prefer those with documented auto-delete (e.g., upload-based tools that delete within hours by default, plus archive systems with retention-policy-based deletion).

3.6. Document the right-to-erasure response process

Under GDPR Article 17, you have one month (extendable to three) to respond to an erasure request. Document the workflow: identify the data subject, locate all systems holding their data, execute the deletion, document the response. PDF-format records in shared file systems and email archives are frequent gaps.

3.7. Maintain encryption inventory

For audit purposes, maintain a list of where encryption is applied, what algorithm, what key management. This is part of ISO 27001 Statement of Applicability for A.8.24 and is increasingly expected by SOC 2 auditors.

3.8. Have a process for legacy unencrypted PDFs

Most organizations have years of historical PDFs in unencrypted form on shared drives. Document the plan: retrofit encryption where feasible, segregate to controlled-access storage where not, document the residual risk in the risk register.

---

Section 4: Redaction Quality (8 items)

Redaction is where compliance frameworks meet PDF technical reality, and where the gap is widest. The next eight items address the technical and procedural standard.

4.1. Never rely on visual-overlay redaction

Drawing a black rectangle on top of text does not remove the text. The Manafort 2019 court filing, the 2003 UK Iraq dossier, the 2010 WikiLeaks State Department cables, and countless less-public cases failed because the redaction was a visual overlay, not a content removal. Reference: OCR has identified improper PDF redaction as a leading cause of HIPAA compliance violations.

4.2. Use true redaction tools that remove the underlying content stream

The tool must modify the PDF’s actual content stream — removing the text and image data, replacing the region with an opaque area in the content stream itself. Adobe Acrobat Pro’s Redact tool, Foxit’s Redaction tool, and imisspdf’s redaction-with-flatten workflow are examples that handle this correctly.

4.3. Sanitize metadata after redaction

PDF metadata commonly includes the original filename, author, edit history, software used, and sometimes XMP fragments with additional sensitive content. Adobe Acrobat’s Sanitize Document action removes these. Most cheaper tools do not. Verify by inspecting the output’s metadata before considering the redaction complete.

4.4. Flatten or rasterize for high-stakes redactions

For court filings, regulatory disclosures, SAR responses, and any redaction that may be scrutinized: flatten the PDF (remove all layer information) or rasterize the redacted page (re-render as image and re-OCR without the redacted regions). This is the forensically secure standard.

4.5. Test redaction output by copy-paste extraction

Open the redacted PDF in a separate viewer (preferably one different from the tool that created it). Try to select and copy text from the redacted regions. If anything copies out, the redaction has failed. Make this a standard QA step before any redacted PDF leaves the organization.

4.6. Verify redaction in text-extraction utility

Beyond visual copy-paste, run the redacted PDF through a text-extraction utility (pdfttotext, PDFBox extraction, or similar). If the redacted content appears in the extracted text, the redaction has failed. This catches cases where copy-paste blocks in the viewer but the underlying text is still present.

4.7. Maintain a redaction process document

For each category of redaction (SAR response, blind-review resume, court filing, research de-identification), document the tool, the steps, and the QA validation. This document supports both audit response and training of new staff.

4.8. Train staff on the difference between visual and true redaction

This is one of the most common training gaps. Many staff members have never been told that a black rectangle in their PDF tool is not the same as a content removal. A 15-minute training session demonstrating the failure mode is sufficient and prevents most incidents.

---

Section 5: E-Signature Compliance (6 items)

E-signature is the most legally-tested PDF feature. Get this right and a wide range of documents become legally executable digitally.

5.1. Confirm ESIGN/UETA conformance for US transactions

The federal ESIGN Act (2000) and UETA (adopted by 47 states + DC) give electronic signatures the same legal effect as wet signatures for most transactions. Confirm the e-signature platform meets ESIGN’s requirements: intent to sign, consent to electronic business, association with the record, and retention.

5.2. Confirm eIDAS tier for EU transactions

eIDAS (EU Regulation 910/2014) defines three tiers: Simple Electronic Signature (SES, lowest), Advanced Electronic Signature (AES, medium), and Qualified Electronic Signature (QES, highest — legally equivalent to wet signature across EU). For high-stakes contracts in the EU, QES via a Qualified Trust Service Provider (QTSP) is the safest choice.

5.3. Require certificate of completion with IP, timestamp, document hash

The audit trail is the evidence in any dispute. The certificate of completion should document the signer’s identity, IP address, geolocation, timestamp, authentication method used (email, SMS, KBA), and a cryptographic hash of the signed document.

5.4. Use Knowledge-Based Authentication (KBA) or stronger for high-stakes signatures

For signatures on documents that may be challenged (large contracts, settlement agreements, real estate closings), KBA or higher-tier authentication (digital certificate, eIDAS QES) provides stronger evidentiary weight than email-link authentication alone.

5.5. Retain signed documents and audit trails per legal-record retention

E-signature platforms typically retain signed documents and audit trails for several years; verify the retention period aligns with the legal-record retention requirement for the document type. eIDAS imposes 5-year retention on AES/QES audit data.

5.6. Document which document categories are e-signable vs require wet signature

Most contracts are e-signable. Wills, testamentary trusts, and certain notarized documents may still require wet-ink in many jurisdictions. Document the categories so staff don’t accidentally e-sign documents that require wet signature.

---

Section 6: Audit Trail (6 items)

Audit trails are the documentation that makes everything else verifiable. They are the most-requested artifact in any compliance audit.

6.1. Maintain an immutable audit log for restricted-document access

Who accessed what document, when, and from where. ISO 27001:2022 Annex A.8.15 (Logging) requires this. HIPAA 45 CFR 164.312(b) requires audit controls. GDPR Article 32 requires the ability to ensure ongoing confidentiality, integrity, and availability.

6.2. Review audit logs regularly

Audit log existence is not sufficient — the logs must be reviewed. The 2017 Memorial Healthcare $5.5M HIPAA settlement specifically cited failure to regularly review audit logs as a contributing factor. Establish a documented review cadence (typically weekly for high-risk systems, monthly for medium-risk).

6.3. Retain audit logs per applicable retention rule

Audit logs typically need to be retained for at least the retention period of the underlying data, often longer. GDPR Article 30 requires the ROPA to be available to the supervisory authority on request; the supporting audit logs may be requested too.

6.4. Protect audit logs from tampering

Audit logs must themselves be tamper-evident or tamper-resistant. Write-once storage, cryptographic chaining, or independent log-management systems prevent retroactive modification of the audit trail.

6.5. Include PDF-tool events in the audit scope

When a user opens, modifies, prints, exports, or shares a restricted PDF, the action should be logged. Cloud tools log within their platform; locally-processed files require endpoint logging (EDR, DLP, or operating-system audit).

6.6. Test audit log completeness annually

Run table-top exercises: “Document who accessed File X in the last 90 days.” If the answer requires consulting multiple systems with mismatched timestamps, your audit log architecture has gaps. Document the gaps in the risk register.

---

Section 7: Incident Response (5 items)

Incident response is what happens when prevention fails. The 2017 Memorial Healthcare settlement, the 2020 Premera Blue Cross settlements, and most major HIPAA enforcement actions involved IR-process failures as well as preventive-control failures.

7.1. Maintain a written PDF-specific incident response procedure

Generic IR plans often don’t address PDF-specific incidents (accidentally emailed unredacted contract, uploaded PHI to unvetted vendor, lost laptop with restricted PDFs). A documented procedure that names PDF scenarios is faster to execute under pressure.

7.2. Define escalation criteria for PDF-related incidents

Not every incident is a breach. Define the criteria for escalation to the DPO, legal, and (if relevant) the supervisory authority. Pre-defined criteria reduce decision time during an actual incident.

7.3. Test the procedure with table-top exercises annually

A documented procedure that has never been exercised is not a real procedure. At least annually, run a table-top: “An employee uploaded an unredacted employee file to a free PDF tool. What do we do in the next 24 hours?” Capture the gaps and update the procedure.

7.4. Maintain pre-drafted notification templates

Under GDPR Article 33, you have 72 hours to notify the supervisory authority. Drafting the notification from scratch during an active incident wastes those hours. Maintain templates for supervisory authority notification, data subject notification, and internal communication.

7.5. Document IR contacts and authority

Who can make the call to notify the supervisory authority? Who can engage outside counsel? Who can suspend a vendor’s access? These contacts and authorities should be documented in the IR procedure and reviewed when personnel change.

---

Section 8: Breach Notification (5 items)

Breach notification timelines are tight and the rules differ by jurisdiction. Knowing the rules in advance is critical.

8.1. GDPR breach notification within 72 hours

Under GDPR Article 33, the controller must notify the supervisory authority without undue delay and not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to rights and freedoms. The 72-hour clock starts from awareness, not from the breach itself. The processor must notify the controller without undue delay.

8.2. HIPAA breach notification within 60 days for most breaches

Under the HIPAA Breach Notification Rule (45 CFR 164.400-414), covered entities must notify affected individuals without unreasonable delay and not later than 60 days after discovery. Breaches affecting 500+ individuals must be notified to HHS within 60 days and the media within 60 days. Breaches affecting fewer than 500 may be reported annually.

8.3. UU PDP breach notification within 3 days

Under Indonesia’s UU PDP 27/2022 Article 46(3), the personal data controller must notify affected data subjects and the relevant regulator within 3x24 hours after becoming aware of the personal data protection failure.

8.4. State-specific breach notification (US)

All 50 US states have data breach notification laws. Timelines vary from “without unreasonable delay” to specific day counts. California (CCPA) has specific consumer notification requirements. Maintain a state-by-state notification matrix if you operate across multiple US states.

8.5. Document the data subject notification process

Notification to affected individuals must include the nature of the breach, contact details for the DPO, likely consequences, and measures taken or proposed to address the breach. Pre-drafted templates that are jurisdiction-specific reduce reaction time.

---

Section 9: Cross-Border Data Transfer (5 items)

Cross-border transfers of personal data via PDF workflows are one of the most-overlooked compliance gaps.

9.1. Map cross-border PDF data flows

For each PDF processing workflow involving personal data, document: source jurisdiction (where the data subject is), processing jurisdiction (where the tool processes the file), and storage jurisdiction (where the file rests). Cross-border flows trigger Chapter V (GDPR) and equivalent provisions in other frameworks.

9.2. Use Standard Contractual Clauses for non-adequate jurisdictions

Under GDPR Articles 44-50, transfers to non-adequate third countries require a transfer mechanism: SCCs (most common), Binding Corporate Rules, adequacy decision, or one of the limited Article 49 derogations. The European Commission’s 2021 SCCs are the current standard.

9.3. Conduct Transfer Impact Assessments (TIAs)

Post-Schrems II (2020), SCCs alone may not be sufficient — a TIA documents the destination country’s surveillance and rule-of-law environment and any supplementary measures (encryption, pseudonymization, contractual). EDPB guidance specifies the TIA framework.

9.4. Apply UU PDP cross-border rules for Indonesian data

Under UU PDP Article 56, transfers of personal data outside Indonesia require either: an adequate level of protection in the recipient country, or sufficient and binding data protections, or the data subject’s consent for transfers without other safeguards. Document the basis for each cross-border transfer of Indonesian personal data.

9.5. Re-evaluate after major legal changes

Schrems III, EU-US Data Privacy Framework challenges, post-Brexit UK adequacy reviews, and similar legal developments can invalidate existing transfer mechanisms. Schedule annual review of cross-border transfer documentation.

---

Section 10: Right to Erasure and Data Subject Rights (5 items)

Data subject rights are the most-exercised compliance area in 2026 — and the most-failed.

10.1. Document the data subject access request (SAR) workflow

Under GDPR Article 15 (and equivalents under UK GDPR, CCPA/CPRA, UU PDP), the data subject can request a copy of their data. Response timeline is typically one month. Workflow: identify the requester, locate all systems holding their data, compile the response, redact third-party data, deliver securely.

10.2. Maintain a system inventory for data subject rights

For each data subject rights request, you need to know every system that may hold their data. Maintain a documented system inventory that supports this — including PDF archives, email systems, and backup systems. Gaps here are common audit findings.

10.3. Use true redaction in SAR responses

The SAR response must include the data subject’s data but exclude third-party data. This means redacting the names and information of other employees mentioned in a performance review, for example. Use true redaction — visual overlays defeat the purpose if the third party’s data is still recoverable.

10.4. Document erasure scope and limits

Under GDPR Article 17, the right to erasure is not absolute — it doesn’t override legal retention obligations or legitimate interests with sufficient weight. Document for each document category whether erasure is feasible and what exceptions apply. Pre-documenting this speeds response time and reduces denial-letter drafting effort.

10.5. Verify erasure across all systems including backups

When an erasure is executed, verify that the data is actually removed from all systems. Immutable backups create complexity — document the policy (typically: erasure applies to active systems immediately, backups age out per backup retention, and the data subject is informed of this).

---

Quick reference: regulatory citations summary

Framework	Key articles for PDF security
GDPR (EU + UK)	Art. 5 (principles), 6 (lawful basis), 9 (special categories), 17 (erasure), 25 (privacy by design), 28 (processor), 30 (ROPA), 32 (security), 33 (breach notification), 35 (DPIA), 44-50 (transfers)
HIPAA (US)	45 CFR 164.308 (administrative), 164.310 (physical), 164.312 (technical), 164.502 (uses/disclosures), 164.504(e) (BAA), 164.514(b) (de-identification), 164.400-414 (breach notification)
UU PDP (Indonesia)	Art. 5 (rights), 16-19 (cross-border), 35 (security), 40 (DPO), 45 (DPIA), 46 (breach notification), 55 (penalties), 56 (cross-border)
ISO 27001:2022 Annex A	A.5.12 (classification), A.5.23 (cloud), A.5.34 (privacy), A.7.4 (physical), A.8.15 (logging), A.8.24 (cryptography), A.8.28 (secure coding)
Other relevant	FTC Safeguards Rule (US financial), CCPA/CPRA (California), LGPD (Brazil), Swiss FADP, eIDAS (EU e-sign), ESIGN/UETA (US e-sign), EU AI Act (recruitment AI)

---

How this checklist maps to the in-browser architectural pattern

A recurring theme across all ten sections is that the architecturally simplest workflow — in-browser PDF tools where the file never leaves the user’s device — closes most of the checklist items without per-vendor negotiation:

• No Article 28 / 164.504(e) processor relationship because no vendor receives the data (Sections 1.5, 2.1, 2.2).
• No cross-border transfer to evaluate because no transfer happens (Section 9).
• No vendor breach risk for documents processed locally (Sections 2.5, 7).
• No sub-processor list to monitor (Section 2.4).
• No DPA / BAA / SCC chain to maintain (Sections 2.2, 9.2).

This isn’t a marketing claim; it’s a structural property. For routine confidential document work, an in-browser tool simplifies the compliance posture by removing the third-party processing step. For workflows that genuinely need cloud routing (multi-party signing, transaction archive, cross-functional collaboration), use one vendor with a signed DPA/BAA, not twelve free tools that nobody catalogued.

This two-tool pattern — one in-browser tool for daily local work + one approved cloud vendor with full documentation — covers most real-world business compliance scenarios at a fraction of the policy overhead of trying to document a dozen free tools.

Using this checklist for audit prep

When an ISO 27001 surveillance audit, SOC 2 audit, HIPAA risk assessment, or GDPR supervisory authority inquiry is upcoming:

1. Walk Section 1 to confirm classification scheme is current and document inventory is accurate.
2. Walk Section 2 to confirm vendor register is complete (this is where shadow-IT findings happen).
3. Walk Section 3 for evidence of encryption and retention policy enforcement.
4. Walk Section 4 with a sample redaction — auditors increasingly test this.
5. Walk Section 6 for audit-log evidence with sampled queries.
6. Walk Sections 7-8 for IR plan and breach-notification template currency.
7. Walk Section 9 for cross-border transfer evidence (this is the post-Schrems II focus area).

Pre-walk each section before the auditor arrives. Document the walk in the compliance file with date and version of each artifact.

Try the in-browser PDF tool referenced throughout

For the daily-work side of the two-tool pattern, imisspdf runs every common PDF tool in your browser — merge, split, compress, convert, OCR, sign, edit, watermark, redact, page numbers, and the rest. No upload, no signup, no daily limit, no file-size cap beyond your device’s RAM. Free, with no premium tier gating the core features. Because no data ever reaches our servers, there is no processor relationship to document for routine confidential work — which closes a substantial portion of the checklist above by architecture rather than by paperwork.

Open imisspdf →

Download as PDF or DOCX

This checklist is itself a working document. To export this article as a portable PDF or DOCX for team use:

• As PDF: open this page, then use your browser’s print-to-PDF or use any PDF tool to capture the page as a portable document. For local processing without uploading, imisspdf’s HTML-to-PDF tool handles this in-browser.
• As DOCX: copy the content into Microsoft Word, Google Docs, or LibreOffice for collaborative editing. The checklist format translates well to a working document for team review.

Many compliance teams print Sections 2, 4, 6, and 8 as standing checklists for vendor reviews, redaction QA, audit-log reviews, and breach notification drills.

Frequently asked questions

The FAQ block at the top of this article covers the most common questions compliance officers ask when starting on PDF security. For deeper industry-specific analysis, see our PDF tools for healthcare (HIPAA), PDF tools for lawyers (ABA Rule 1.6), PDF tools for HR (GDPR + EU AI Act), and PDF tools for real estate (ESIGN + state law) guides.

Sources

• GDPR full text — Articles 5, 6, 25, 28, 30, 32, 33, 35
• HHS — HIPAA Security Rule (45 CFR 164.308-164.312)
• HHS — HIPAA Breach Notification Rule (45 CFR 164.400-414)
• eCFR — 45 CFR 164.504 Business Associate Agreement
• HHS — 45 CFR 164.514(b) De-identification Safe Harbor
• Indonesia UU PDP No. 27/2022 — full text and analysis
• ISO 27001:2022 Annex A controls reference
• EU AI Act — Annex III high-risk AI
• European Data Protection Board — Guidelines on personal data breach notification
• HHS OCR — Memorial Healthcare $5.5M HIPAA Settlement (2017)
• HIPAA Journal — Premera Blue Cross OCR penalty ($6.85M)
• eIDAS Regulation (EU 910/2014) — e-signature framework
• American Bar Association — Embarrassing Redaction Failures (Manafort)
• FTC Safeguards Rule (revised 2023)
• California CPRA — final regulations

Frequently asked questions

Related articles