The auditor portal:
one link instead of a shared drive.

• A scoped, read-only access link per engagement
• Comment and evidence-request threads on each requirement
• Audit package export as JSON or Markdown
• Append-only, SHA-256 hash-chained audit trail with a verify endpoint
• Evidence freshness from expiry dates, so stale items show as stale

Audits slow down on requests, not on findings: the auditor asks for a sample, someone searches a shared drive, a screenshot arrives without a date, and the question goes round again. Putting requests and evidence in one place, against the requirement they belong to, removes most of those loops.

Read-only and scoped matters too. The auditor sees the engagement's framework and period and nothing else, and cannot change anything they are assessing.

1. Create an engagementOpen an engagement for the framework and period being audited, for example SOC 2 Type 2 for the last twelve months. Everything the auditor sees is scoped to it.
2. Invite the auditorSend a share link to the auditor's email. Each link is stored only as a hash, expires within 90 days at most, and can be revoked at any time.
3. Auditor reviews the evidenceThe auditor reads the requirements, the controls mapped to them and the evidence behind each control, with freshness shown from each item's expiry date.
4. Requests go in a threadWhen the auditor needs more, they raise an evidence request or a comment on the requirement it concerns. Your team answers in the same thread, so nothing is lost in email.
5. Export the packageExport the audit package as JSON or Markdown for the auditor's working papers, and revoke the link when the engagement closes.

Each entry includes the hash of the one before it, so altering or deleting a past entry breaks the chain from that point on, and anyone can check the chain is intact. That turns "trust us, nothing was edited" into something the auditor can test.

Audits slow down because of the back-and-forth over evidence, not because of findings. An auditor asks for a sample, someone searches for it, the file arrives without a date or a clear link to the requirement, and the question goes round again. Each loop costs days, and a twelve-month SOC 2 Type 2 period can produce dozens of them.

Keeping each request on the requirement it concerns, next to the evidence already there, removes most of those loops. The auditor can see what exists before asking, and your team can see exactly what is outstanding.

A hash-chained audit trail proves that past entries have not been altered or removed since they were written. Each entry stores a SHA-256 hash that includes the hash of the entry before it, so changing any past entry breaks every link after it, and a verification run shows exactly where.

That matters to an auditor because they rely on your records for the whole period, not just the day of fieldwork. ISO 27001 clause 7.5 asks for documented information to be controlled and Annex A 5.33 asks for records to be protected; a trail anyone can verify is a direct answer. The evidence ledger explains how evidence itself is recorded.

Evidence is fresh when it was collected recently enough to describe the control as it runs now. The portal marks each item as fresh, expiring within 30 days, or expired, from the expiry date on the item, so an auditor can see stale evidence at a glance instead of discovering it in a sample.

This does not collect evidence for you. Items arrive from connectors, the SDK or uploads, and their freshness reflects when that happened. An expired item is a prompt to collect it again, not something the portal hides.

Yes. ISO 27001 clause 9.2 requires internal audits at planned intervals, and the same engagement can be used for an internal auditor as for an external one. Running the internal audit the same way also gives you a rehearsal for the external one. See the ISO 27001 page and the SOC 2 guide for what each audit covers.

• The system description and the scope of the audit
• Evidence for each control across the whole observation period, not one day
• Samples: specific changes, access reviews, incidents and new joiners
• Proof that evidence was not edited after the fact
• Exceptions and how they were handled
• Policies with approval dates and version history
• A single point of contact and a place to raise requests

• It does not collect or refresh evidence on demand; evidence comes from connectors, the SDK and uploads
• It does not perform the audit or issue an opinion; that is the auditor's job
• It does not give the auditor write access to controls, evidence or settings
• It does not replace the auditor's own working-paper system; the export feeds it
• Share links cannot stay open beyond 90 days; long engagements need a new link

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: the evidence ledger and SOC 2 Type 1 vs Type 2.