How to Generate SOC 2 PDF Evidence Packs Automatically from Screenshots

A SOC 2 PDF evidence pack is the artifact your auditor opens when they sample a control test. It holds the screenshots, the narrative that explains what each screen proves, the timestamps, the tester identity, and a signature that lets the auditor confirm nothing changed after capture.

Building one by hand takes most of a workday per control once you count the capture, the write-up, the formatting, and the upload. At Screenata the work belongs to Vera, the agent who runs your compliance program. She captures the screens with context attached, drafts the step narrative, maps each artifact to the control it supports, assembles the PDF, signs it, and puts it in front of you for review before it goes anywhere. The pack is the visible output of a chain that starts at a policy sentence and ends at a signed file.

This guide covers what a pack contains, how Vera builds one, what auditors check when they open it, and how the same evidence gets reused across frameworks.

What a SOC 2 PDF Evidence Pack Contains

The parts of a complete pack

A pack is self-contained. An auditor should be able to open the file, understand what was tested, and reach a conclusion without asking you for anything else. That means it carries:

A cover page with the control ID, the test date, the environment, and the result.
A test summary stating the objective and the outcome in plain language.
The test procedure, listing the steps performed and the pass criteria.
The screenshots themselves, in the order they were captured.
A description under each screenshot explaining what it demonstrates.
Supporting system records, such as the audit log entry that corroborates the screen.
Metadata: who ran the test, from what browser and environment, at what time.
An appendix holding the raw capture data, the file hashes, and the signature block.

Why auditors ask for PDFs

Auditors work through a sample list, and they want each item to arrive as one reviewable file. A PDF gives them that. It is portable, it archives cleanly in their workpapers, its text is searchable, and it does not invite the version confusion that comes with editable documents. When a pack is signed and hashed, the auditor can also confirm the file they received is the file that was generated.

The formats that cause friction are the ones that break that property. Loose screenshot files arrive without context about what control they support. Word documents can be edited after the fact, so the auditor has to ask how the file was produced. Video recordings force a reviewer to watch several minutes to answer a question a single frame would settle. Evidence scattered across three systems means the auditor spends their sampling time chasing links.

What auditors send back

The follow-up questions are predictable, and they are the reason packs get rebuilt. Auditors ask who ran the test, when it ran relative to the audit window, whether the screen came from production, what the tester's role was, and whether the underlying system records agree with what the screen shows. A pack that answers all five up front does not generate a second round.

Where Evidence Packs Fit in Vera's Work

How Vera collects evidence

Screenshots are one input among several. Across a typical SOC 2 program, Vera's evidence breaks down roughly as follows:

How Vera collects it	Share	What it covers
API scans	~70%	Cloud configuration, identity logs, repository settings, endpoint posture
Automated screenshots	~9%	Application UI states, RBAC tests, admin consoles APIs cannot read
Guided collection	~9%	Controls that need a specific path walked in a specific order
Inbox ingestion	~5%	Forwarded emails and Slack file drops, classified on arrival
Dashboard uploads	0%	Nothing here. Uploading files by hand is the work being replaced

The remainder is attestation: the answers only a person can give, which Vera chases in Slack or Teams.

A PDF pack can hold any of these. Most packs for CC6 access controls lean on screenshots because the control lives in your product's UI. Packs for CC7 monitoring controls lean on scan output and log excerpts. The format is the same either way.

Why the pack is an output, not the product

A dashboard flags that a control needs evidence and leaves the collection to you. Vera runs the test, gathers the artifacts, and produces the pack. The pack matters because it is the point where an auditor meets the work, but the work itself is the scan, the capture, the attestation chase, and the signing pipeline behind it. Every pack traces back to a policy sentence, through a testable claim, to a control test, to the signed artifact you are looking at.

The Manual Way to Build One Pack

Before automating anything, it helps to see where the hours go. Here is the sequence a compliance owner runs by hand for a single control test.

Step 1: Capture the screens

Log in as the test user, walk the workflow, and screenshot each meaningful step. Save the files with names you will still understand next quarter. Roughly 15 minutes, longer if you have to redo a step you clicked past.

Step 2: Organize the files

Rename the captures in chronological order, confirm no step is missing, and check that nothing is blurry or cropped in a way that hides the URL bar. About 10 minutes.

Step 3: Write the narrative

Open a document, add a cover page with the control ID, write the objective, then describe each screenshot: what it shows, why it satisfies the control, and when it happened. Timestamps get typed in by hand from the file metadata. This is the long part, usually around 45 minutes.

Step 4: Format the document

Insert the images, add captions, make the headings consistent with last quarter's pack, add page numbers, and build a table of contents. About 25 minutes.

Step 5: Export and name the PDF

Export, confirm the images survived the conversion at readable resolution, check the file size, and rename it to your convention. About 5 minutes.

Step 6: File it in your GRC platform

Navigate to the control, upload the file, add the test date and tester, and mark the control as tested. About 10 minutes.

What that costs over a year

The sequence runs about 110 minutes per control test. A modest SOC 2 program tests around 20 controls quarterly, which is 80 tests a year, or roughly 147 hours. At a loaded cost of $75 an hour that is about $11,000 of internal time, and it is time taken from the person who can least afford it, usually a founder, a CTO, or the one engineer who understands the access model. The larger cost is the timing: the work gets deferred until the audit is close, and then it happens in one exhausting week.

How Vera Builds the Pack

Step 1: Capture with context attached

For controls that live behind your application's UI, Vera captures through the Screenata browser extension. Each capture carries more than an image:

{
  "control": "CC6.1",
  "step": 2,
  "action": "navigate",
  "url": "https://app.company.com/admin/users",
  "http_status": 403,
  "captured_at": "2026-07-14T10:01:30.412Z",
  "tester": "compliance@company.com",
  "tester_role": "Viewer",
  "dom_snapshot": true,
  "viewport": "1920x1080"
}

The DOM snapshot is what separates this from a picture. It records that the HTML elements existed on the page as shown, which answers the auditor question about whether an image was assembled after the fact. The timestamp is NTP synced. The tester identity travels with the capture rather than being typed in later.

Step 2: Write the step narrative

A vision model reads each capture the way a reviewer would: button labels, error messages, role indicators, banners, and state signals such as a denial or a success confirmation. From that it drafts the description that sits under the screenshot, and it scores whether the capture demonstrates the control rather than merely relating to it. Low-confidence captures get flagged for your review instead of being written up with confident language.

A drafted description for an access denial reads like this:

At 10:01:30 UTC on July 14, 2026, a user holding the Viewer role attempted to open the administrative user list at /admin/users. The application returned HTTP 403 and displayed the message "Access Denied. Insufficient Permissions." The corresponding denial was written to the audit log at 10:01:31 UTC for user viewer@company.com. This supports CC6.1, which requires that access to protected assets be restricted to authorized users.

Step 3: Map the evidence to controls

Each artifact attaches to the control test that requested it, and to any secondary control it also supports. An access denial screenshot supports CC6.1 as its primary control, and the log entry behind it also supports the logging requirement in CC6.6. Mapping happens at capture time because the capture was triggered by a control test, so nothing has to be reconciled later.

Step 4: Assemble and sign the PDF

Vera composes the pack, hashes each file with SHA-256, signs the bundle, and attaches an RFC 3161 timestamp from an independent authority. The signature and the hash list live in the appendix. An auditor can verify the pack with the free Open Attest CLI without holding a Screenata account, because the format is published as an open spec. Assembly takes seconds; the review that follows is where your time actually goes, and that is deliberate.

Anatomy of a Signed Evidence Pack

Cover page

Control ID, control name, test date, environment, tester, result, and a document ID that stays stable across regenerations. If the test was run by Vera rather than a person, the cover names her as "Vera (AI)" so the auditor knows what produced the artifact.

Test summary

Two paragraphs: what the test was trying to establish, and what happened. Written to be read by someone who does not know your product.

Test procedure

The steps performed, the pass criteria, the frequency of the test, and the date of the previous run. The previous-run date matters more than teams expect, because it is how an auditor confirms the control operated throughout the period rather than once.

Step-by-step evidence

One screenshot per page at full resolution, with its description, its timestamp, and the specific detail the auditor should look at. Text inside the images is indexed, so an auditor searching a hundred pages for "Access Denied" finds it instead of scrolling.

Appendix and proof chain

Raw capture metadata, per-file SHA-256 hashes, the signature block, the timestamp token, and the claim chain: the policy sentence this test supports, the claim derived from it, the control test that ran, and the artifact IDs produced. An auditor who wants to work backwards from a policy statement to the proof can do it inside one file.

Worked Example: CC6.1 Role Restriction

The control requires that access to protected information assets is restricted to authorized users. The test asks whether a low-privilege role can reach an administrative surface.

Vera runs the sequence with a dedicated Viewer test account: authenticate, navigate to the admin user list, capture the denial, then open the audit log and capture the recorded event. Four captures, each with its DOM snapshot and timestamp. She pairs them with the API-side evidence she already holds: the role definitions pulled from your identity provider, and the list of accounts currently holding the Admin role.

The pack that comes out has both halves. The API evidence proves the role model is what you say it is. The screenshots prove the model is enforced in the product. Auditors ask for both, and teams that supply only the first spend the following week supplying the second.

Worked Example: CC7.2 Change Management

The control asks whether changes are authorized, tested, and approved before they reach production.

Most of this evidence arrives through the GitHub integration: the pull request, the reviewer approval, the status checks, the merge commit, and the actor on each. Vera pulls it on a schedule and holds the population.

The screenshots cover what the API record does not settle. A branch protection settings page proves that self-merging is blocked by configuration rather than convention. A deployment confirmation screen ties the merge to the release that actually shipped. When an auditor samples a specific change, the pack for that change carries the API record and the two UI captures in one file.

What Vera Redacts Before a Pack Is Filed

Evidence packs travel to auditors, and sometimes to prospects through a trust center. Anything sensitive that appears on screen gets masked at capture time rather than after the file is built.

Redaction covers customer email addresses and names in user lists, API keys and tokens visible in settings pages, payment identifiers, and personal data in any record that is not the subject of the test. The compliance markers stay visible: role labels, permission toggles, timestamps, status indicators, and the URL. A redacted pack still proves the control; it just does not hand over your customer list along the way.

If a screen cannot be captured without exposing something that should not leave your systems, Vera flags it and asks how you want to handle it instead of guessing.

Packs for Failed Tests

A failed test still produces a pack, and the pack is more useful than the passing one.

It records what was expected, what actually happened, and when. If a Viewer role reached the admin panel and received a 200 response, that screen goes in the pack with the description saying so. Vera then opens a remediation ticket describing the gap and the affected control, and she re-verifies after a human applies the fix. She does not apply the fix herself.

The value is timing. A gap found in week three of your observation window is a fix. The same gap found by an auditor in month eleven is an exception in your report.

Review Before Export

No pack leaves your workspace without a human looking at it. Vera assembles, scores, and stages it; you approve it. The review screen shows the captures, the drafted descriptions, the control mapping, and any item the vision model scored below the confidence threshold.

Reviewers usually change two things: the wording of a description that reads oddly for your product's vocabulary, and the control mapping when a capture supports a secondary criterion nobody tagged. Both edits are cheap at review time and expensive after an auditor has the file.

When a Pack Goes to an Existing Audit Workspace

Plenty of teams already run Drata or Vanta and are mid-cycle with an auditor who works inside that workspace. Export exists for that case. A finished pack can be pushed to the matching control in your existing platform, so the evidence lands where your auditor already looks.

This is compatibility, not the reason to use Vera. The value is that the evidence got collected, described, and signed without a person spending 110 minutes on it. Where the file ends up is a routing question.

A Week in Vera's Compliance Cadence

Packs are a byproduct of a schedule that runs whether or not anyone is thinking about the audit.

Daily, 6:00 AM: evidence freshness check across the control matrix. Anything aging out gets queued for recapture.
Daily, 6:15 AM: readiness snapshot, showing which controls have current evidence and which do not.
Daily, 6:30 AM: Slack briefing. What she collected, what she needs from a person, what is overdue.
Weekly, Monday: cloud and repository scans across connected providers.
Quarterly: access review cycle scheduled and orchestrated, with Vera chasing the reviewers.
Annually: risk assessment refresh.

Evidence collected on this cadence covers the observation window continuously. Evidence collected the month before an audit covers the month before the audit, which is the finding auditors write up most often.

The Attestation Work Vera Takes Off Your Plate

Some evidence has no API and no screen. Someone has to confirm that the quarterly access review actually happened, that a terminated employee's laptop was collected, or that a vendor's SOC 2 report was reviewed.

Vera DMs the person who knows, in Slack or Teams. If there is no answer in 24 hours she reminds them. At 48 hours she escalates. When the answer arrives it is captured as an attestation with the responder's identity and timestamp, and it becomes part of the pack for the control it supports.

This is the work that quietly consumes a compliance owner's week, and it is the part a dashboard cannot do because a dashboard has no way to ask.

Collect Once, Map Across SOC 2, ISO 27001, and HIPAA

Frameworks overlap more than their documentation admits. An MFA enforcement capture supports SOC 2 CC6.1, ISO 27001 Annex A access control requirements, and the HIPAA authentication safeguard at 164.312(d).

Vera collects against a shared canonical control catalog, so one capture attaches to every control it satisfies. The second framework costs a fraction of the first, because most of the evidence already exists and only the gaps need new collection. Packs are generated per framework from the same underlying artifacts, with the mapping section reflecting whichever standard the auditor is working from.

What a Pack Costs You

The manual path for a mid-size SOC 2 program runs about $85,000 in the first year once you total a GRC platform subscription, a fractional compliance consultant, and the auditor fee. Evidence prep sits inside that as internal hours nobody bills for.

Screenata is $499 a month for Type II, with SOC 2 Type I starting at $299. Add an audit fee and the first year lands around $18,000. The evidence packs are not a line item; they are what the subscription produces.

Quality Standards Auditors Judge Packs Against

What a strong pack has

A clear cover page with the control ID, date, and result. A summary that states the objective in a sentence. Screenshots at 1920x1080 or better with legible text. A timestamp on every action. Tester identity on every step. Consistent structure across quarters, so the auditor reviewing Q3 recognizes the layout from Q1. A table of contents and page numbers. A verifiable signature.

What gets flagged

Missing or hand-typed timestamps. Screenshots cropped so the URL bar is gone. No tester identity. Formatting that changed between quarters, which forces the auditor to re-learn the document. Evidence captured outside the observation window. Editable file formats. Descriptions that assert a control works without showing the state that proves it.

File naming

A pattern that sorts and self-describes works best:

CC6.1_RBAC_Access_Controls_2026-Q3_20260714.pdf
CC7.2_Change_Management_2026-Q3_20260716.pdf
CC8.1_Vulnerability_Management_2026-Q3_20260718.pdf

The shape is control ID, test name, year and quarter, capture date. Names like evidence_july.pdf or screenshot_final_v2.pdf cost the auditor time and cost you a follow-up email.

File size

A pack with 3 to 5 screenshots typically lands between 2 MB and 4 MB. Six to ten screenshots runs 4 MB to 8 MB. Above roughly 10 MB, compress the images to 80% quality, which stays well above the threshold where text remains readable, or split a very long workflow into two packs by phase.

What Happens After You Certify

The report is not the end of the program. Type II covers an observation window, and the next window starts the day the current one closes.

Vera keeps running the same cadence: daily freshness checks, weekly scans, quarterly access reviews, packs regenerated as evidence ages out. When the next audit begins, the evidence for the period already exists, so the prep work is a review pass rather than a rebuild. Teams that stop collecting after the report arrives spend the following year repeating the scramble.

Frequently Asked Questions

Can I customize the pack template?

Yes. Logo, company name, colors, and the confidentiality marking in the header are configurable, and you can choose whether to include the executive summary, the methodology section, and the raw data appendix. The signature block and the hash list are not optional, because they are what make the pack verifiable.

What format are the screenshots inside the PDF?

High-resolution PNG, at 1920x1080 or better, without compression artifacts. Text stays legible when the auditor zooms in, which matters for permission tables and log excerpts.

Can I regenerate a pack if I find an error?

Yes. Descriptions can be edited and the pack rebuilt from the saved capture data. Regeneration produces a new signature and timestamp, and the previous version remains in the vault, so the history of what was produced when stays intact.

How secure is the pack?

Each file carries a SHA-256 hash, the bundle is signed, and an RFC 3161 timestamp from an independent authority proves when it was created. Signing keys can be platform-managed or brought from your own AWS, GCP, or Azure KMS. Access to packs is logged.

Can auditors search the text?

Yes. Descriptions, methodology, control IDs, timestamps, and the text inside the screenshots are all indexed, so an auditor can search across a full quarter of evidence rather than opening files one at a time.

What happens if a test fails?

The pack is still generated and records the deficiency: expected behavior, actual behavior, and the affected control. Vera opens a remediation ticket and re-verifies once a person applies the fix.

Does Vera build packs without a person involved?

She assembles them and stages them for review. A human approves before anything is filed or exported. For judgment calls, such as whether a partially redacted screen is safe to share, she asks rather than deciding.

Can I still use Drata or Vanta alongside this?

Yes. Finished packs export to the matching control in an existing audit workspace. That path exists so an auditor already working inside your platform does not have to move.

Key Takeaways

Evidence packs are the artifact auditors actually review, so they are worth getting right the first time. The manual build runs about 110 minutes per control test, which is roughly 147 hours a year for a typical program.

Vera captures the screens with DOM snapshots and NTP-synced timestamps attached, drafts the step narrative with a vision model, maps artifacts to controls at capture time, and assembles a signed PDF you approve before it is filed.

Screenshots are about 9% of the evidence in a SOC 2 program. The other 91% comes from API scans, guided collection, inbox ingestion, and attestations Vera chases in Slack. The pack format is the same regardless of the source.

Signed and hashed packs answer the questions auditors ask first: who ran this, when, from where, and has it changed since. Packs generated on a continuous cadence cover the whole observation window instead of the weeks before the audit.

At $499 a month, the first-year cost lands near $18,000 against roughly $85,000 for a GRC platform plus a consultant plus the auditor.

Learn More About SOC 2 Automation

For a complete guide to automating SOC 2 evidence collection, including how evidence packs fit into a continuous compliance program, see our comprehensive SOC 2 automation guide.