--- title: "PDF SDK compliance and security evaluation checklist for enterprise teams (2026)" canonical_url: "https://www.nutrient.io/blog/pdf-sdk-compliance-security-checklist/" md_url: "https://www.nutrient.io/blog/pdf-sdk-compliance-security-checklist.md" last_updated: "2026-05-27T11:52:23.512Z" description: "A checklist for enterprise teams evaluating PDF SDKs on security, compliance, and risk — covering SOC 2, HIPAA, eIDAS, ESIGN, PDF/A, and redaction." --- **TL;DR** - Get the SOC 2 Type 2 report under NDA. Ask who runs the annual penetration test and request the executive summary. - Confirm PAdES support for eIDAS, ESIGN/UETA, and long-term validation (LTV) for archival signatures as advised by relevant legal experts in your operating jurisdiction. - Redaction must be tested for your use case. Even strong redaction is never 100 percent — review what the SDK documents about its limits. - Ensure you have a signed Business Associate Agreement (BAA) as advised by your legal or procurement team in advance of any evaluation involving PHI. - PDF/A and PDF/UA are separate ISO file format standards, not certifications. Ask for veraPDF validation results across both. Most enterprise PDF SDK evaluations come down to rendering quality and edge case handling first — teams typically arrive at a commercial SDK after off-the-shelf or open source options fall short on tricky documents, performance, or support. Compliance is the second gate. Even after an SDK clears the technical bar, deals can still stall during compliance review — when a security team flags an unaudited vendor, when a customer contract requires on-premises deployment and the SDK only offers SaaS, or when a legal team discovers that “digital signature” support doesn’t actually mean eIDAS-compliant PAdES signatures. The categories below are the ones that consistently surface in enterprise security questionnaires and compliance reviews. This checklist assumes you’ve already evaluated the SDK for rendering quality, performance, and API design. It covers the compliance layer that procurement teams evaluate separately. ## Why PDF SDK compliance is a procurement risk PDF SDKs process some of the most sensitive documents in any organization. A vendor that handles this content needs to meet the same standards as any other data processor in your environment. The risks of skipping compliance due diligence include: - **Audit failures** — A PDF SDK without an SOC 2 Type 2 audit will fail most vendor risk assessments during customer security reviews. - **Data residency violations** — Cloud-processed documents that cross jurisdictions without explicit region controls can breach contractual or regulatory obligations to keep data within agreed-upon regions. - **Invalid signatures** — A [digital signature](https://www.nutrient.io/sdk/digital-signatures/) that doesn’t meet eIDAS or ESIGN standards may not hold up in court or regulatory review. - **PHI handled without a BAA** — As the covered entity, processing protected health information through a vendor without a signed Business Associate Agreement and appropriate technical safeguards may leave you exposed under the HIPAA Security Rule. ## The six evaluation categories The sections below cover the six areas that consistently shape PDF SDK procurement decisions: security certifications and audit posture, data handling and deployment model, digital signature compliance, document security features, archiving and accessibility standards, and vendor risk and supply chain. Each one maps to a question security and legal teams will raise during a typical enterprise review. ### 1. Security certifications and audit posture A vendor without current third-party audits can’t make credible security claims. Most enterprise security questionnaires open with this section — get it wrong and the rest of the evaluation doesn’t happen. | Requirement | What to look for | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SOC 2 Type 2 | Most recent Type 2 report from an active audit cycle, not just Type 1 | | Penetration testing | Annual testing by a named third-party firm, summary available under NDA | | CVE response | Documented SLOs for vulnerability remediation, with named upgrades available where stricter SLAs are required | | Supply chain transparency | Ability to provide a software bill of materials (SBOM) under NDA when supply chain audit is required for your deployment | | Engine maintenance | Active maintenance of the rendering engine. A vendor whose engine is a maintained fork of a widely used open source project (e.g. Chrome’s PDFium) inherits upstream security patches from Google and the broader community before they reach the vendor — proprietary engines carry the full mitigation burden alone | | SCA | Software composition analysis for third-party components, with documented patching cadence | **Ask your vendor:** - Can you provide your current SOC 2 Type 2 report under NDA? - Who conducts your penetration testing and how frequently? - What are your published SLOs for patching critical CVEs, and do you offer a stricter SLA where required? - Who maintains your rendering engine, and how quickly do you patch upstream vulnerabilities? - Do you run SCA scans on every release? _Related: [How to scale document workflows in compliance with regulations](https://www.nutrient.io/blog/document-workflows-compliance-conundrum/)_ ### 2. Data handling and deployment model Many enterprise contracts and regulations require documents to be processed within agreed-upon regions or infrastructure boundaries. The specific source of that requirement varies — GDPR has provisions around transfers to third countries, HIPAA imposes its own technical safeguards (without a strict residency rule), and US federal programs such as FedRAMP often pull in residency requirements via the regulated agency’s own rules. | Requirement | What to look for | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------- | | On-premises deployment | Self-hosted option available, no mandatory cloud telemetry | | Air-gapped environments | SDK functions without internet access | | Data residency | Cloud processing stays within authorized or agreed-upon regions | | Encryption at rest | AES-256 or equivalent, with customer-managed keys available | | Encryption in transit | TLS 1.2 minimum, TLS 1.3 preferred | | FIPS 140-2/140-3 | Required where PDF encryption or digital signing must run on FIPS-validated crypto; not all viewer-only use cases need it | Healthcare organizations and government contractors typically require on-premises or private cloud deployment. Confirm what external network calls (if any) the SDK makes during processing for the configuration you plan to deploy — some SDKs send telemetry or validate licenses against external servers, which can be a blocker in air-gapped environments. Look for documented air-gapped configurations. Client-side processing is worth a separate look. If documents are handled entirely in the user’s browser or on your servers, the vendor never acts as a data processor — that’s a cleaner compliance position than on-premises alone, and it’s the answer compliance teams find easiest to sign off on. **Due diligence questions:** - Does the SDK make any external network calls during document processing? - Is on-premises deployment available without a cloud dependency? - Does the SDK support client-side processing where documents never leave the user’s browser or your infrastructure? - Where is data processed in your hosted/cloud offering, and can we restrict to specific regions? _Related: [HIPAA-compliant document management in hospitals](https://www.nutrient.io/blog/hipaa-compliant-document-management-hospitals/)_ ### 3. Digital signature compliance What vendors call [digital signature](https://www.nutrient.io/sdk/digital-signatures/) support ranges from drawn-on annotations to full PAdES with LTV. For regulated industries, the specific standard matters — not just whether signatures are technically present. We’ve compiled the information below for your convenience, but we can’t provide legal or regulatory advice, so we recommend verifying all requirements with your organization’s legal counsel. | Standard | Applies to | What to confirm | | ------------------------------------------ | ----------------------------------- | -------------------------------------------------------------------------------------- | | PAdES (PDF Advanced Electronic Signatures) | EU eIDAS compliance | PAdES-B-B, PAdES-B-T, PAdES-B-LT, PAdES-B-LTA levels | | LTV (long-term validation) | Archival and legal use | Signature remains verifiable after certificate expiry | | ESIGN/UETA | US federal and state legal validity | Legally binding electronic signatures in US jurisdictions | | FDA 21 CFR Part 11 | Life sciences, clinical trials | Audit trails, electronic records integrity, controlled signing | | eIDAS Qualified Signatures | EU high-assurance workflows | Integration with Qualified Trust Service Providers (QTSPs) | | XAdES/CAdES | XML and binary document workflows | Required if signing non-PDF files (e.g. XML invoices, CMS data) in regulated workflows | For most enterprise use cases, confirm at minimum: PAdES support with LTV for EU workflows, ESIGN/UETA compliance for US contracts, and the ability to sign using certificates from third-party certificate authorities (CAs). For government and defense deployments with planning horizons of five or more years, ask whether post-quantum signature readiness is on the vendor’s roadmap. NIST has approved post-quantum algorithms (ML-DSA, SLH-DSA), and the PDF specification is being updated to support them. Vendors that can speak to a plan here reduce future migration risk. For a deeper explanation of PAdES, CAdES, XAdES, and eIDAS compliance levels, see [the complete guide to digital signatures](https://www.nutrient.io/blog/complete-guide-digital-signatures/). **Questions to ask:** - Which PAdES conformance levels do you support (B-B, B-T, B-LT, B-LTA)? - Can signatures be validated after the signing certificate expires (LTV)? - Do you support signing with certificates from third-party CAs, including keys backed by a hardware security module (HSM)? - What is your roadmap for post-quantum digital signature algorithms? _Related: [The difference between digital and electronic signatures](https://www.nutrient.io/blog/digital-vs-electronic-signatures/)_ ### 4. Document security features [Redaction](https://www.nutrient.io/sdk/redaction/) is where vendor claims most often diverge from reality. Some SDKs apply a black rectangle on top of sensitive content but leave the underlying text in the PDF structure — extractable with any text tool. True redaction removes the underlying content from the file permanently. Even strong redaction is never 100 percent bulletproof — data doesn’t have to be visually rendered to remain in the file — so review the SDK’s documented limits and test it for your use case. Nutrient publishes guidance on what redaction can and can’t do; see [the security of redaction](https://www.nutrient.io/guides/web/redaction/introduction-to-redaction.md#security-of-redaction). Security enforcement also has to live at the API level, not just in visual UI controls a user can bypass. | Feature | What to verify | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Redaction | Permanent removal of underlying content (not just a visual overlay) — verify with API documentation and review the SDK’s documented limits | | [Encryption](https://www.nutrient.io/api/pdf-security-api/) | Password and certificate-based encryption with permission controls | | DRM/permissions | PDF-level permission flags for printing, copying, and editing — note that no client-side viewer can fully prevent access to the underlying file | | Audit trails | Immutable logging of document access, modification, and signing events | | Watermarking | Dynamic watermarks that survive conversion and printing | | Sanitization | Configurable controls to disable or strip risky content (such as JavaScript), with the option to review metadata and embedded objects before sharing — note that aggressive sanitization can affect file integrity | **Verify these directly:** - Is redaction implemented as permanent content removal or a visual overlay? - Can you verify irreversibility through the API documentation? - Does the SDK provide configurable options to disable JavaScript or strip metadata and hidden content when required, and what are the tradeoffs for file integrity? _Related: [What’s hiding in your PDF](https://www.nutrient.io/blog/whats-hiding-in-your-pdf/) · [Incremental and full save in PDFs](https://www.nutrient.io/blog/incremental-and-full-save-in-pdfs/)_ ### 5. Archiving and accessibility standards “PDF/A support” can mean anything from full ISO conformance to partial coverage that misses common edge cases. [PDF/A](https://www.nutrient.io/sdk/pdf-a-conversion/) and [PDF/UA](https://www.nutrient.io/solutions/pdf-ua-conversion/) are separate ISO standards, and vendors often claim support for both without distinguishing partial from full conformance. Ask for veraPDF validation results on a representative sample of your document types — not a marketing claim. | Standard | Purpose | What to verify | | ---------------- | -------------------------------------------------- | ------------------------------------------------------------- | | PDF/A-1b/2b/3b/4 | Long-term archiving (ISO 19005) | veraPDF conformance rate, which levels are supported | | PDF/UA-1/2 | Accessibility for assistive technology (ISO 14289) | veraPDF conformance rate, tagged PDF output | | WCAG 2.1 AA | Web accessibility | If the viewer/UI component is involved, not just output files | **Questions to ask:** - What is your veraPDF conformance rate for PDF/A and PDF/UA conversion? - Which PDF/A conformance levels do you support (1b, 2b, 3b, 4)? - Do you have test results available for our specific document types? _Related: [Accessibility, untangled: What it actually means, and why it matters](https://www.nutrient.io/blog/accessibility-untangled-why-it-matters-guide/)_ ### 6. Vendor risk and supply chain The vendor organization is part of your risk profile — not just the product. | Area | What to evaluate | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Business Associate Agreement (BAA) | May be required for HIPAA — confirm availability before evaluating for PHI use cases | | Subprocessor list | Which third-party services handle your data in a hosted deployment | | Incident response | Documented incident response process and breach notification approach (timelines vary by jurisdiction and contractual obligations) | | Data retention and deletion | How long processed documents are retained, right-to-erasure support | | Contractual SLAs | Uptime guarantees, support response times, liability caps | | Escrow | Source code escrow availability for long-term production risk mitigation | | IP indemnification | Vendor indemnifies against IP claims from embedded open source components | For HIPAA-regulated use cases, obtain a signed BAA before any evaluation that involves actual patient data — even in a staging environment. _Related: [How Athena Intelligence built AI agents for regulated enterprises with Nutrient’s document infrastructure](https://www.nutrient.io/blog/athena-nutrient-enterprise-ai-compliance/)_ ## Industry requirements matrix | Requirement | Healthcare (HIPAA) | Financial services | Legal/contracts | Government (US federal) | EU regulated | | ---------------------- | ------------------ | ------------------ | --------------- | ------------------------ | ------------ | | SOC 2 Type 2 | ✅ Required | ✅ Required | ✅ Recommended | ✅ Required | ✅ Required | | BAA | ✅ Required | — | — | — | — | | On-premises/air-gapped | ✅ Often required | ✅ Often required | — | ✅ Often required | Regional | | FIPS 140-2/140-3 | — | ✅ Often required | — | ✅ Required | — | | PAdES/eIDAS | — | ✅ Recommended | ✅ Required (EU) | — | ✅ Required | | ESIGN/UETA | ✅ Required | ✅ Required | ✅ Required (US) | ✅ Required | — | | FDA 21 CFR Part 11 | Life sciences only | — | — | — | — | | PDF/A archiving | ✅ Recommended | ✅ Required | ✅ Required | ✅ Required | ✅ Required | | PDF/UA accessibility | ✅ Recommended | ✅ Required | — | ✅ Required (Section 508) | ✅ Required | | CCPA/CPRA | — | ✅ If CA-based | ✅ If CA-based | — | — | | GDPR data residency | — | — | — | — | ✅ Required | ## Five questions to send to your PDF SDK vendor Send these as part of your security questionnaire before entering a paid evaluation. A vendor that hesitates on any of them is telling you something useful. 1. **"Can you provide your current SOC 2 Type 2 report and most recent penetration test summary under NDA?"** — A vendor that can’t produce these as part of a security review or that pushes back on sharing them under NDA is telling you something. Allow time for the response — a thorough security questionnaire can take longer to turn around than a single-document request. 2. **"Does your SDK make any external network calls during document processing, can it operate in a fully air-gapped environment, and does it support client-side processing where documents never leave the browser?"** — This is often critical for healthcare, government, and financial services environments. 3. **"Is redaction implemented as permanent removal of underlying content at the PDF structure level — not just a visual overlay — and what limits do you document?"** — Test the answer yourself with a text extraction tool on a redacted file, and review the vendor’s documented limits. 4. **"What is your veraPDF conformance rate for PDF/A and PDF/UA conversion, and can you provide test results for our document types?"** — Low conformance rates should raise questions for regulated archiving use cases. 5. **"Will you sign a Business Associate Agreement before we use the SDK with protected health information?"** — Any HIPAA-covered vendor should answer yes immediately. ## How Nutrient meets enterprise compliance requirements We built Nutrient for organizations where deals depend on passing compliance review. More than 15 percent of Global 500 companies use Nutrient to process sensitive documents, and the categories on this checklist map directly to how we approach security and compliance. - **SOC 2 Type 2** — Audited infrastructure, report available under NDA. Visit our [Trust Center](https://trust.nutrient.io/) for details - **Client-side and on-premises deployment** — The Web SDK processes documents entirely in the browser with no data sent to Nutrient servers. [Document Engine](https://www.nutrient.io/sdk/document-engine/) runs fully self-hosted for server-side workflows, including air-gapped environments - **PAdES with LTV** — eIDAS-compliant [digital signatures](https://www.nutrient.io/sdk/digital-signatures/) with long-term validation, supporting both client-side and server-side [signing workflows](https://www.nutrient.io/sdk/solutions/signing/) - **[Redaction](https://www.nutrient.io/sdk/redaction/)** — Industry-leading redaction with permanent removal of underlying content at the PDF structure level, verifiable via API; see our [guidance on redaction security](https://www.nutrient.io/guides/web/redaction/introduction-to-redaction.md#security-of-redaction) for documented limits - **[PDF/A](https://www.nutrient.io/sdk/pdf-a-conversion/) and [PDF/UA](https://www.nutrient.io/solutions/pdf-ua-conversion/)** — High veraPDF conformance across both standards, validated on document samples customers bring to evaluation - **BAA available** — For HIPAA-covered deployments - **HSM-backed digital signing** — For workflows where signature key material must stay inside validated hardware, Nutrient supports signing through external HSMs and key-management services that customers already operate. Note that Nutrient’s Core cryptography library (Botan) is not FIPS 140-validated, so customers with strict FIPS-validated cryptography requirements for PDF encryption or digital signing operations should confirm fit with us before procurement. For viewer-only workflows that don’t perform cryptographic operations in the SDK, FIPS requirements are typically handled by the integrating application’s network and storage layers - **Battle-tested rendering engine** — Nutrient maintains an optimized fork of [PDFium](https://www.nutrient.io/blog/why-pdfium-is-a-trusted-platform-for-pdf-rendering/), the open source engine behind Chrome, Edge, and Dropbox. The team has invested in this fork for more than a decade, applying security patches and contributing improvements back. Customers get the reliability of an industry-standard engine with active vendor-managed maintenance Learn more about our [security practices](https://www.nutrient.io/security/) and [SDK security, compliance, and privacy solutions](https://www.nutrient.io/sdk/solutions/security-compliance-privacy/). ## FAQ #### What is SOC 2 Type 2 and why does it matter for PDF SDK evaluation? SOC 2 Type 2 verifies that security controls work consistently over a defined audit period (commonly 3–12 months), rather than at a single point in time (that’s Type 1). Audit window lengths and refresh cadences vary by vendor, so for procurement, ask the vendor for their most recent Type 2 report and confirm when the next audit period closes — a current report from an active audit cycle is what to look for. #### What is the difference between electronic signatures and digital signatures in PDF SDKs? [Electronic signatures](https://www.nutrient.io/sdk/electronic-signatures/) (typed names, checkboxes, drawn marks) show intent. [Digital signatures](https://www.nutrient.io/sdk/digital-signatures/) use cryptographic certificates to prove identity and detect tampering — they’re what regulated industries actually require (eIDAS in the EU, ESIGN/UETA in the US, FDA 21 CFR Part 11 in life sciences). Confirm your SDK supports PAdES for PDF-embedded digital signatures, not just visual signature fields. #### What does HIPAA require from a PDF SDK vendor? HIPAA requires that any vendor processing protected health information (PHI) on your behalf signs a Business Associate Agreement (BAA) before processing begins. Beyond the BAA, the SDK must support the HIPAA Security Rule’s technical safeguards: encryption of PHI at rest and in transit, access controls, audit logging of document access and modifications, and the ability to deploy in an environment where PHI doesn’t leave your controlled infrastructure. A cloud-only PDF SDK that processes documents on vendor-managed servers may require a BAA and careful review of data residency and subprocessor policies. #### What is PDF/A and when is it required? Regulated archiving — legal document retention, healthcare records, financial filings — requires PDF/A (ISO 19005). The standard restricts features that could make documents unreadable over time: JavaScript, encryption, external dependencies. There are multiple conformance levels (1b, 2b, 3b, 4). Confirm which your workflow requires and verify the vendor’s veraPDF conformance rate against your own document samples — low conformance rates should raise questions. #### Is redaction in PDF SDKs always permanent? Not always. Some SDKs fake it by drawing a black rectangle over content while leaving the text intact in the PDF structure. This is extractable with any text tool. Genuine redaction removes the underlying content from the file, but no implementation is 100 percent guaranteed because data doesn’t have to be visually rendered to remain in a PDF. Test it yourself: Apply a redaction via the API and then run text extraction on the output. If the redacted content is still extractable, the implementation isn’t fit for redaction-sensitive workflows. Review the vendor’s documented limits and confirm with your own legal or compliance team whether the implementation meets your specific requirements. --- ## Related pages - [The business case for accessibility: Five ways it drives enterprise value](/blog/5-ways-accessibility-drives-enterprise-value.md) - [Advanced Techniques For React Native Ui Components](/blog/advanced-techniques-for-react-native-ui-components.md) - [Best Document Viewers](/blog/best-document-viewers.md) - [The CTO’s AI playbook: Why accountability architecture beats orchestration](/blog/cto-ai-playbook-accountability-architecture.md) - [The CEO’s AI playbook: Why decision architecture beats model selection](/blog/ceo-ai-playbook-decision-architecture.md) - [Document Viewer](/blog/document-viewer.md) - [Digital Signatures](/blog/digital-signatures.md) - [base_url tells WeasyPrint where to resolve relative asset paths](/blog/how-to-generate-pdf-reports-from-html-in-python.md) - [Linearized Pdf](/blog/linearized-pdf.md) - [Nutrient Vs Conga Composer](/blog/nutrient-vs-conga-composer.md) - [Online Document Viewer](/blog/online-document-viewer.md) - [Process Flows](/blog/process-flows.md) - [or](/blog/sample-blog-updated.md) - [Vector Pdf](/blog/vector-pdf.md) - [Why Your Ai Agent Hallucinates Pdf Table Data](/blog/why-your-ai-agent-hallucinates-pdf-table-data.md) - [What Are Annotations](/blog/what-are-annotations.md) - [Convert an HTML file to PDF.](/blog/top-ten-ways-to-convert-html-to-pdf.md) - [What Is A Vpat](/blog/what-is-a-vpat.md)