01
Chapter one
When a signature actually matters
Standard approval captures 95% of regulated document evidence needs. The other 5% needs a signature that stands up against repudiation. Distinguishing which is which is the first decision.
The word “signature” in document-management conversations often conflates two very different things. Standard approval via the sequential approval workflow is one — a named person authenticated through Entra clicking “Approve” in a governed flow, with the event written to the audit log. That’s enough evidence for most regulated document workflows. The audit log answers every “who approved what” question with attribution, role, version, and timestamp.
A cryptographic signature is something else. It binds the signer’s identity to the exact bytes of the PDF in a way that would fail verification if the PDF were modified. It’s what’s needed when the document’s legal weight requires non-repudiation — when the signer can’t credibly say later “that wasn’t me” or “that wasn’t what I signed.”
Standard approval
Sufficient for the majority
Audit log captures who approved, in what role, against which version, with what timestamp. Sufficient for ISO 9001 clause 8.5, HIPAA §164.312(b), GDPR Article 5(2), and for the bulk of 21 CFR Part 11 §11.10(e) audit-trail requirements. Most document approvals live here.
PAdES signing
When cryptographic binding matters
Required when the signed document will face legal scrutiny beyond the organization's own compliance program — external contracts, regulator submissions, signed policies where repudiation risk exists, third-party obligations. PAdES adds cryptographic proof to standard approval.
Standard approval sufficient
Internal SOPs, policies that apply only within the organization, procedures reviewed by the compliance team. The audit log is the evidence. PAdES adds no value.
PAdES signing warranted
Contracts, regulatory submissions, signed attestations to third parties, customer-facing agreements. The signature travels outside the tenant; cryptographic binding is the defense.
Advanced PAdES required
Clinical-trial protocol submissions, high-value contracts, regulatory filings where signer identity verification is expected by the receiver. Advanced PAdES adds SMS/ID verification.
Qualified or AGID required
Italian AGID-specific obligations, eIDAS qualified electronic signatures, CAdES-specific workflows. Not supported in our DocuSign integration — a separate tool is needed.
The compliance lesson: only pay for cryptographic binding when the document's legal weight genuinely requires it. For most approval flows, the standard audit log is the evidence the regulation asks for.
02
Chapter two
PAdES simple vs advanced — the two levels
Both levels bind the signature to the PDF cryptographically. The difference is identity verification — how sure the receiver can be that the signer is who they say they are.
PAdES (PDF Advanced Electronic Signature) is an ETSI standard that defines how electronic signatures embed in PDF documents. The DocuSign integration supports two PAdES levels, both with full cryptographic binding:
| Property |
PAdES simple |
PAdES advanced |
| Cryptographic binding |
Yes — signature bound to PDF bytes |
Yes — same cryptographic binding |
| Identity verification |
Email authentication + signer's M365 identity via click-through |
Identity verification layer — SMS code, government-ID check, or KBA (knowledge-based auth) |
| Non-repudiation strength |
Strong within an organization |
Strong enough for external contractual disputes |
| Typical use |
Internal signed policies, standard contracts with established partners, routine regulatory documents |
High-value contracts with new counterparties, regulatory submissions to agencies, clinical-trial sponsor signatures |
| Per-signature cost |
Lower (DocuSign base tier) |
Higher (DocuSign advanced tier + identity-verification ancillary cost) |
The distinction matters because simple PAdES handles the majority of customer signing needs at significantly lower per-signature cost. Defaulting to advanced everywhere is expensive. Defaulting to simple everywhere misses cases where the receiver expects identity verification.
03
Chapter three
What's cryptographically bound
Cryptographic binding is specific. What it protects against, and what it doesn't, determines whether it's the right tool for your use case.
A PAdES signature binds five things into a verifiable cryptographic structure embedded in the PDF:
The PDF bytes
A hash of the PDF content. Any modification after signing invalidates the signature.
The signer's name + email
From the DocuSign envelope, tied to the authenticated session that produced the signature.
Timestamp of signing
From DocuSign's timestamping authority. Independently verifiable.
Issuing authority
DocuSign's signing certificate issued by a trusted CA. Chain of trust verifiable by any PDF viewer.
Signature purpose
The meaning of the signature as declared at signing — "approved as Chief Compliance Officer," "signed as contracting party," etc.
What’s not covered by cryptographic binding:
- The internal provenance of the PDF before signing. The signature says “this exact PDF was signed by this person.” It doesn’t say anything about who authored the PDF or what happened to it before the signing ceremony.
- The signer’s intent beyond the declared reason. Legal disputes over intent still live in contract interpretation.
- Events after the signature, unless they re-break the binding. Copying the signed PDF doesn’t affect the signature; modifying it does.
For the typical regulated document workflow — where the audit log captures everything before signing and the cryptographic signature captures the signing moment itself — these two evidence layers together are comprehensive.
04
Chapter four
DocuSign as ceremony, not archive
A subtle but important distinction in how the integration is wired: DocuSign runs the signing ceremony; the signed PDF goes back to SharePoint as the authoritative version. DocuSign isn't the archive.
Many DocuSign integrations leave the signed PDF in DocuSign’s vault, with a link back from the originating system. That pattern creates two places the “authoritative version” lives — a split that complicates audits, data-residency requirements, and retention policy.
Our integration works differently. DocuSign is the signing mechanism only — where the cryptographic ceremony happens, identity is verified (for advanced PAdES), and the signature is applied. The moment signing completes, the signed PDF is returned to SharePoint and becomes the authoritative published version. DocuSign does not retain the document as the system of record; SharePoint does.
1
Approval step reached
Signing step activates
The sequential approval flow reaches a step configured as "DocuSign-signed." The system constructs a DocuSign envelope from the current PDF and sends it to the designated signer's email.
2
Signer receives link
Authentication in DocuSign
Signer opens the link, reviews the PDF in DocuSign's viewer, completes any identity verification required (for advanced PAdES), and signs. The signature is cryptographically applied to the PDF.
3
Signed PDF returns
Back to SharePoint as authoritative version
DocuSign returns the signed PDF to the active-lifecycle product via webhook. The PDF replaces the unsigned version in the document's history; the audit log captures the signing event with all cryptographic metadata.
✓
Publication proceeds
Signed PDF as the published version
Approval flow continues to the next step (or completes). The signed PDF is what end-users see in the public area. DocuSign's copy becomes a redundant reference — the authoritative source is in your tenant.
Why this architecture matters. Data residency: the signed document stays in your M365 tenant. Audit scope: DocuSign is a signing vendor, not a system of record — your compliance scope doesn’t expand to include DocuSign as a document archive. Retrieval: the signed PDF lives where every other document lives, so audit retrievals work the same way regardless of whether a specific document was signed or not.
05
Chapter five
When simple PAdES is enough
Specific signing contexts where simple PAdES provides sufficient non-repudiation without the cost of advanced identity verification.
Internal signed policies
Code of conduct, acceptable-use policies, internal commitments signed by employees. The signer's identity is already established by Entra authentication; simple PAdES adds signature binding without identity-verification overhead.
Contracts with repeat counterparties
Renewal contracts, SOWs with existing vendors, commercial amendments with known partners. The identity relationship is already established; simple PAdES provides the cryptographic commitment without new identity verification.
Standard regulatory filings
Routine submissions to regulators who accept simple PAdES as standard — most regulatory bodies have moved to accepting standard PAdES as meeting their electronic-signature requirements.
4
COMPLIANCE ATTESTATIONS
Internal compliance attestations
"I have reviewed this policy and attest to compliance" — the acknowledgment is by a known employee. Simple PAdES is more than sufficient for the attestation's legal weight inside the organization.
06
Chapter six
When advanced PAdES is required
Contexts where the receiver genuinely needs identity verification — and where simple PAdES would be non-compliant or inadequate.
High-value external contracts
Contracts over specific financial thresholds where the receiver expects identity verification. Many large enterprise customers mandate advanced PAdES for contracts they sign with suppliers.
First contract with new counterparty
When no prior identity relationship exists, advanced PAdES provides the identity-verification layer that simple PAdES lacks. Especially valuable for international parties where in-person verification isn't possible.
Clinical trial sponsor signatures
Clinical-trial protocols, investigational-product release records, sponsor-approved documents where regulatory bodies expect verified-identity signing.
Financial commitments above threshold
Signed financial commitments, large purchase orders, treasury authorizations — contexts where the organization's own controls mandate identity verification at the signing step.
A practical recommendation. Configure the default for each document type during implementation. SOPs and internal policies default to standard approval (no signing). External contracts default to simple PAdES. High-value contracts (above a threshold defined by the organization) default to advanced PAdES. Signing behavior then matches the document type automatically.
07
Chapter seven
What we don't support
Signing modes that fall outside the DocuSign PAdES integration, and what customers who need them should do.
Being explicit about what’s not supported prevents surprises during implementation. The DocuSign integration covers PAdES simple and advanced. It does not cover:
CAdES signatures
CAdES is a detached-signature standard used in some regulatory contexts (particularly in European public-sector workflows). Different trust model than PAdES. Not supported; customers needing CAdES use dedicated external tools.
Qualified electronic signatures (eIDAS)
Qualified e-signatures under eIDAS require a qualified signature-creation device and a qualified certificate from a qualified trust service provider. DocuSign provides advanced e-signature, not qualified. For qualified requirements, a QTSP-integrated tool is needed.
AGID-specific signing
Italian AGID requirements (digital signature via national smart cards, firma digitale remota) use an Italian-specific trust model. Not supported in our integration. Customers with AGID obligations use a separate tool alongside the DMS.
Handwritten-style signatures without cryptography
"Drawn" or typed signatures that don't include cryptographic binding. Not offered — if the signature doesn't cryptographically bind, it's not materially different from the audit-log approval, so we don't add a weaker mechanism on top.
For customers needing these modes: most run the DMS and the specialized signing tool in parallel. The DMS governs the document lifecycle; the specialized tool handles the specific signing mode. The signed output from the specialized tool returns to the DMS as a regular document if further governance is needed. This hybrid is common in Italian public-sector customers and in eIDAS-qualified-signature contexts.
08
Chapter eight
Signing as an approval-step type
Rather than a separate workflow, PAdES signing is configured as a type of approval step. One flow, one audit trail, one integrated experience.
In the sequential approval workflow, each step is configured with a type. Standard approval is one type (click-through approval, audit log captures). DocuSign signing is another — the step notifies the signer through DocuSign instead of through the standard approval interface, runs the signing ceremony, and returns the signed PDF to the flow.
From the document-management perspective, the signing step behaves like any other approval step. The flow continues to the next step on success. The audit log captures the signing event with all cryptographic metadata. The signer’s identity is tracked. The version binding is maintained. The flow halts on failure (rejection, signing timeout) the same way it does on any other rejection.
One workflow, not two
Signing happens inside the approval flow, not in a separate DocuSign-initiated process. The author doesn't hand off to a different tool; the system routes through DocuSign and returns.
One audit trail
Signing events write to the same audit log as approval events. Full document history is in one place — no reconciliation between DocuSign's log and the DMS's log.
Signed PDF is the version
The signed PDF becomes the major version at publication. Not a separate "signed copy" alongside an "original version." One authoritative document, with the signature embedded.
Authors don't switch tools
The author initiates the approval flow. The signer receives the signing request. Both work inside their own context — the author in the DMS, the signer through their email. No one juggles two applications.
09
Chapter nine
Compliance mapping — Part 11 specifics
Which PAdES properties satisfy which Part 11 clauses — for customers with active Part 11 programs.
| Clause |
Requirement |
How PAdES satisfies it |
| §11.50(a) |
Signed electronic records shall contain printed name of the signer, date and time of signature, and meaning of signature. |
PAdES signature embeds signer name, timestamp, and signing reason in the PDF visibly and cryptographically. |
| §11.70 |
Electronic signatures shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or transferred. |
Cryptographic binding makes excision, copying, or transfer detectable — any such modification invalidates the signature on verification. |
| §11.100(a) |
Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. |
Signatures bind to a named Entra identity (authenticated in DocuSign) — no shared signing accounts. |
| §11.200(a) |
Employ at least two distinct identification components such as an identification code and password. |
Email authentication + M365 credentials (typically MFA-enforced at tenant level) provide two-factor authentication to the signing ceremony. |
| §11.10(e) |
Secure, computer-generated, time-stamped audit trail. |
DMS audit log captures signing event with all cryptographic metadata; DocuSign provides additional signing-side audit trail as redundant evidence. |
The product provides the signing capability customers use in their Part 11 compliance program. It doesn't provide a "Part 11 validated" signing system — that assertion requires the customer's QA validation scope, which remains with the customer's QA team.
10
Chapter ten
Implementation patterns
Three concrete patterns for wiring PAdES signing into the document-type configuration, with rough rules for when each applies.
Pattern 1
Default: no signing
Internal SOPs, policies, operating procedures. Standard approval via audit log is sufficient. Most customers' document types live here. Pricing: no DocuSign consumption.
Pattern 2
Last step: simple PAdES
External contracts with established partners, routine regulatory filings, commercial attestations. The last approval step is configured as DocuSign-signed (simple). Pricing: one simple PAdES transaction per approved document.
Pattern 3
Last step: advanced PAdES
High-value contracts, clinical-trial sponsor signatures, regulatory submissions requiring identity verification. Last step configured as advanced PAdES with required verification method (SMS, KBA, ID). Pricing: advanced PAdES + identity-verification ancillary per transaction.
A configuration tip. Let the document type drive the pattern rather than letting authors decide per document. “All supplier contracts use simple PAdES” as a document-type configuration is more defensible than “the author picks” — the latter invites “I forgot to enable signing” incidents. Document-type defaults enforce policy as structural behavior.
PAdES signing is the last mile of document evidence — the cryptographic commitment that standard approval alone cannot provide. For the subset of documents that genuinely require it, the integration with DocuSign inside the sequential approval flow makes signing an operational detail rather than a separate workflow. For everything else, standard approval captures the evidence regulations actually require.
A 30-minute conversation with our team is usually enough to map which of your document types genuinely need PAdES signing and which can rely on standard approval — avoiding both the cost of over-signing and the compliance gap of under-signing.
