What SOC 2 and ISO 27001 auditors actually check in your eSignature stack

Most compliance programmes treat the eSignature platform as another SaaS tool, reviewed once in a vendor assessment and filed away. That approach fails when a SOC 2 or ISO 27001 auditor reaches the eSignature section of their test procedures.

A signing platform doesn't just store data. It produces legally binding evidence. Auditors who understand this check five control areas that generic SaaS reviews miss entirely. This article covers what those areas are, what evidence you'll be asked to produce, and how to have it ready before fieldwork begins.

Why SOC 2 and ISO 27001 auditors check your eSignature stack specifically

A standard SaaS vendor assessment covers data classification, access controls, encryption at rest and in transit, and incident response. That's adequate for a project management tool or a CRM.

An eSignature platform is different because the output is a legal record. The moment a document is signed, it becomes evidence of a transaction. Evidence has authentication requirements (who signed), chain-of-custody requirements (can the record be shown to be unaltered since signing), and retention requirements (how long is the record kept, and how is deletion controlled).

Under SOC 2, the relevant Trust Service Criterion is Processing Integrity, specifically PI 1.4, which covers whether processing is complete, valid, accurate, timely, and authorised. Under ISO 27001:2022, eSign-specific controls appear in Annex A 8.24 (use of cryptography) and A 5.33 (protection of records). Most generic SaaS vendor assessments don't get close to either.

The five areas an auditor will specifically test:

• Non-repudiation and signer identity evidence
• Audit log integrity and chain of custody
• Certificate and timestamp infrastructure
• Access privilege management
• Document retention, deletion, and backup

Non-repudiation: what the evidence standard looks like

Non-repudiation means you can prove that a specific person, having seen a specific version of a document, expressed agreement at a specific time using an authentication method strong enough that they cannot credibly dispute it later.

For an auditor, this translates into a request for four things: the authentication mechanism used (email OTP, Aadhaar OTP, biometric, or DSC), the document fingerprint at the moment the signer was shown the document, a timestamp tied to a trusted Timestamping Authority, and the IP address of the signing device if your jurisdiction requires it.

If your eSign vendor produces a Certificate of Completion as the audit artefact, check whether that PDF is itself digitally signed. An unsigned completion document is not tamper-evident: anyone with the right software can modify it without leaving a trace. A SOC 2 auditor focused on Processing Integrity will flag this.

FlowVerify's audit trail PDF is PAdES-signed at creation. Any modification after creation invalidates the embedded signature. That makes it tamper-evident: the artefact proves whether it has been changed, rather than simply asserting that it hasn't.

Audit log integrity and chain of custody

Experienced auditors know that logs stored in a writable database can be altered after the fact, including by the vendor's own engineering team. The question they ask — politely, but directly — is: what controls prevent someone with database access from changing a signing event record?

Three answers meet the bar:

• Cryptographic log chaining: each record includes a hash of the previous record, so altering one entry invalidates the chain from that point forward
• WORM storage: the underlying storage tier is configured Write Once, Read Many at the infrastructure level
• Periodic export to immutable storage: logs are written to a bucket the signing application cannot write back to

If your vendor stores audit records in a standard relational database with no chaining and no WORM tier, that is a control gap. A SOC 2 auditor will raise it under PI 1.4 or Availability A 1.2; an ISO 27001 auditor will reference Annex A 8.15 (logging).

Ask your vendor this directly: can you produce a log export for one envelope that lets me verify the chain-of-custody hash? If the response is a PDF download, check whether the PDF is signed. If it's a CSV, ask whether the export includes a hash or signature covering the file content.

Certificate and timestamp infrastructure

This is the control area teams most often overlook because it's invisible until a validation failure occurs years later.

When a document is signed with a DSC, the signing certificate carries an expiry date. Open that document in Adobe Acrobat five years from now and, if no further steps were taken at signing time, you'll see 'Signature validity unknown' or 'Certificate has expired.' The signature is no longer independently verifiable.

The fix is a timestamp from a trusted Timestamping Authority, embedded in the signed PDF at the time of signing. That timestamp anchors the signature to a point in time that can be verified independently of the certificate's expiry.

The auditor question is: what PAdES level does your signing infrastructure produce, and can you demonstrate that a signed document validates offline after the signing cert expires?

For most Indian business agreements with a 5-year retention window, PAdES B-T is sufficient if the Timestamping Authority stays operational. For documents with longer requirements — 10 years under Indian GAAP for certain financial records, or 8 years for specified tax documents — B-LT is safer because it embeds the revocation data in the PDF rather than requiring a live OCSP query at validation time.

Access controls and privilege management

This is the control area where most eSign audits surface at least one finding. The auditor questions:

• Who can send documents for signature?
• Who can void or cancel an envelope after it has been sent?
• Who can download the signed PDF and the audit trail?
• Are those actions logged against the identity of the person who took them?
• Is the user list reviewed on a documented schedule?

For SOC 2 Type II, access reviews need to happen during the audit period and be evidenced with a date and an attesting name. A screenshot of the user list with 'Reviewed by [Name], [Date]' satisfies this. A verbal confirmation does not.

For ISO 27001, access management falls under Annex A 5.15 through 5.18. The expectation is a formal joiner/leaver/mover process that covers the eSign platform as a system handling sensitive records, not just your core product.

The gaps auditors most commonly find:

• Former employees with active accounts in the signing platform — orphaned accounts are the single most common finding
• Admins who can void a signed document with no second-approval requirement and no log entry
• No separation between staff who can send documents and staff who can export the full signed PDF archive

Document retention, deletion, and backup evidence

Signed documents are records. Records have retention schedules. The auditor needs to see that the schedule is defined in policy, enforced by the platform, and auditable after the fact.

Three questions you will be asked:

• Where are signed documents stored, and is that storage within the audit scope?
• What is the retention period, and is deletion automated or manual?
• If a document must be deleted for a DPDP Act erasure request or because the retention period has elapsed, how do you verify deletion was complete, including backup copies?

The gap auditors find most often: the primary document is deleted from the platform UI, but the backup tier still holds a copy. S3 versioning, a point-in-time snapshot, or an archive tier can retain a document the owner believes has been removed. If your DPO signs off on a deletion that isn't complete, that is both a compliance finding and a legal liability.

For FlowVerify: document deletion initiates a soft-delete first, followed by hard deletion on the configured schedule. Backups follow the same schedule with a lag determined by the backup tier. If your regulatory context requires a specific retention window, set it explicitly in account settings. Don't assume platform defaults match your policy.

Building the evidence pack before your auditor asks

The difference between a clean audit and a scrambled one is usually whether evidence was collected before the auditor arrived or during the fieldwork window.

Non-repudiation

• A sample completed envelope with the audit trail PDF showing authentication method, IP, timestamps, and document hash
• Vendor documentation confirming the audit trail is tamper-evident
• Confirmation of PAdES level produced by the platform

Audit log integrity

• Vendor description of their log-chaining or WORM approach, from a security whitepaper or trust page
• A sample raw log export for one envelope

Certificate and timestamp

• List of Certifying Authorities and Timestamping Authorities your vendor uses
• Confirmation of PAdES level and certificate validity period
• Certificate renewal policy documentation

Access controls

• Current user list with roles, exported from the platform
• Dated access review evidence with reviewer name and date
• Joiner/leaver/mover process documentation covering the eSign platform

Retention and deletion

• Screenshot of configured retention settings in the admin panel
• Policy document stating the retention period for each document type you sign
• Evidence of at least one completed deletion, showing it cleared from backup

If your vendor publishes a security whitepaper or a trust page, attach it and note which sections address which controls. Auditors weigh vendor documentation more heavily than your own descriptions for infrastructure-level claims — it shifts accountability to the vendor if their stated controls don't hold.