How to establish excel file integrity for soc 2 type ii audit evidence
- Step 1Hash each evidence file at collection — As soon as an evidence workbook is exported from the source system, drop it into the hasher before anyone opens it. The SHA-256 you record is the integrity baseline for that piece of evidence.
- Step 2Process the file (no configuration) — There is no options panel — the tool reads the bytes locally and goes straight to Process, returning all four digests. Nothing is uploaded, so in-scope customer data stays on your machine.
- Step 3Record the SHA-256 in the evidence register — Log the 64-character SHA-256 next to the evidence ID, the source control/system, the custodian, and your collection date and time (recorded in the register, since the hash itself carries no timestamp).
- Step 4Store the file and report under change control — Place the evidence file and its JSON hash report in a write-once or access-controlled repository so the registered digest predates any review and cannot be quietly altered with the file.
- Step 5Re-hash at review to confirm integrity — When the auditor reviews the evidence, re-hash the file and compare to the registered SHA-256. A match demonstrates the evidence is byte-for-byte the collected artefact.
- Step 6Strip metadata before sharing externally, then re-hash — If the workbook carries internal author names or file paths you don't want to disclose, run the Application Metadata Wiper first, hash the sanitised copy as a separate evidence item, and document the wipe — the byte change is expected and explained.
Evidence integrity workflow stages
Where the hash fits in a SOC 2 evidence lifecycle. SHA-256 is the control value at every stage.
| Stage | Hash action | Recorded where |
|---|---|---|
| Collection | Hash file as exported, before any open | Evidence register (baseline SHA-256) |
| Storage | Store file + JSON report write-once | Access-controlled repository |
| Review | Re-hash and compare to baseline | Auditor's working papers |
| External sharing | Wipe metadata, hash sanitised copy | Production index (separate digest) |
| Change accepted | Re-baseline with change reference | Updated register entry |
Digests and their compliance role
All four are produced in one pass over the raw bytes; no algorithm picker. SHA-1/256/512 via Web Crypto, MD5 via a built-in routine.
| Algorithm | Hex length | Compliance role |
|---|---|---|
| SHA-256 | 64 chars | Primary integrity control value |
| SHA-512 | 128 chars | Higher-assurance cross-check where policy requires |
| SHA-1 | 40 chars | Legacy interop only — not an integrity control |
| MD5 | 32 chars | Populate a legacy GRC MD5 field only; never the control |
Tier limits for evidence hashing
Hashing is byte-only, so file size is the only relevant cap. Excel-family limits.
| Tier | Max file size | Files per run |
|---|---|---|
| Free | 5 MB | 1 |
| Pro | 50 MB | 5 |
| Pro + Media | 200 MB | 20 |
| Developer | 500 MB | unlimited |
Cookbook
A collection-to-review evidence workflow for SOC 2 Type II. Hashes and IDs are illustrative.
Register an evidence file at collection
Export access-review data to Excel, hash it immediately, and log the baseline in the evidence register.
Evidence: EV-2026-Q2-0148 (quarterly access review) File: Access_Review_2026Q2.xlsx Report: sha256 = 3a7bd3e2360a3d29eea436fcfb7e44c7... md5 = ea8c2a6b... (legacy GRC field only) Register entry: EV-2026-Q2-0148 | Access_Review_2026Q2.xlsx source: IAM export | collected 2026-04-03 09:14 SHA-256: 3a7bd3e2360a3d29eea436fcfb7e44c7...
Auditor re-verifies the evidence
At review, the auditor re-hashes the file and matches it against the registered baseline.
Registered SHA-256: 3a7bd3e2360a3d29eea436fcfb7e44c7... Auditor re-hash: 3a7bd3e2360a3d29eea436fcfb7e44c7... Match → evidence is byte-for-byte the collected artefact. Noted in working papers as integrity-verified.
Auditor reproduces the hash independently
The auditor confirms the digest without your tool, strengthening the evidence.
$ shasum -a 256 Access_Review_2026Q2.xlsx 3a7bd3e2360a3d29eea436fcfb7e44c7... Access_Review_2026Q2.xlsx Matches the registered value → independently verified. The control does not depend on JAD's tooling.
Sanitise before sharing with an external auditor
Strip internal author/path metadata, then hash the sanitised copy as its own evidence item.
Original (internal): sha256 = 3a7bd3e2... Run /excel-tools/excel-app-metadata-wiper → Access_Review_2026Q2_clean.xlsx (new bytes) Sanitised copy: sha256 = b1946ac9... Register both; document the wipe so the byte difference between internal and shared copy is accounted for.
Re-baseline after an approved correction
A data correction is approved during the audit period; update the registered digest with the change reference.
Change ref: CHG-2291 (corrected a duplicated user row) Old baseline retired: 3a7bd3e2... (superseded) New baseline: d4735e3a... (CHG-2291) Register entry updated with reviewer and approval date.
Edge cases and what actually happens
Evidence opened and re-saved before review
ModifiedAn .xlsx rewrites its internal Last-Modified timestamp on every save, so opening and saving evidence — even with no edits — changes the bytes and the SHA-256. The re-saved file no longer matches the registered baseline. Capture the baseline before anyone opens the file and keep a sealed copy for the register.
No timestamp inside the hash report
By designThe report lists digests and file size but does not embed a time. A hash proves the file is unchanged, not when it was collected. Record collection date and time in the evidence register, and pair with a timestamping authority if your control framework requires a verifiable time anchor.
Evidence dump exceeds the Free 5 MB cap
Tier limitA large operational export can exceed Free tier's 5 MB per-file limit. Row count is irrelevant — only byte size. Use Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB) for bulk evidence.
Baseline captured after the file was already edited
Invalid baselineA baseline only proves integrity from when it was taken. If you hash evidence after it was opened, sorted, or corrected, the baseline endorses the altered state. Always hash at the point of export, before any human interaction.
Auditor's hash differs from your register
InvestigateIf the auditor's re-hash doesn't match, the file changed between collection and review — a re-save, a corrupted transfer, or an unauthorised edit. Investigate the cause; a value-level Range Diff against a sealed copy shows whether content actually changed.
MD5 used as the integrity control
Use SHA-256MD5 has practical collisions and is not an acceptable integrity control for audit evidence. The tool emits MD5 only to populate legacy GRC fields. Record SHA-256 as the control value; see why SHA-256 over MD5.
Evidence stored where it can be edited alongside the hash
Weak controlIf the registered digest sits in the same writable location as the file, anyone who edits the file can also rewrite the recorded hash, defeating the control. Store the baseline write-once or in a system with its own immutable audit trail, separate from the evidence file.
Workbook round-tripped through a cloud editor
ModifiedViewing or exporting an .xlsx through Google Sheets or some online editors rewrites the file, changing the hash even with identical values. Register and verify against the original exported file, not a cloud-round-tripped copy.
Macro-enabled evidence workbook
SupportedThe hasher reads raw bytes, so .xlsm evidence hashes fine; the VBA project is part of the digest. If your control requires macro-free evidence, strip macros with the VBA Macro Stripper and register the sanitised copy's new hash.
Frequently asked questions
How does a SHA-256 hash support SOC 2 evidence integrity?
Hash each evidence workbook at collection and register the SHA-256. At review, re-hashing and matching the registered value proves the file is byte-for-byte the collected artefact, supporting an integrity assertion that maps to Common Criteria around detecting unauthorised changes to data. The control is reproducible because anyone can re-compute the SHA-256.
Does the hash report include a collection timestamp?
No. The report contains the digests and file size only — there is no embedded timestamp, and a hash cannot prove when a file existed. Record the collection date and time in your evidence register, and use a timestamping authority if your framework requires a verifiable time anchor.
Will hashing upload my in-scope customer data?
No. Hashing runs in your browser via the Web Crypto API over bytes read locally; nothing is uploaded. Evidence containing in-scope customer data never leaves your device, so the integrity step does not create a disclosure.
Can the auditor verify my registered hashes themselves?
Yes. Because the tool hashes raw bytes, the auditor can run sha256sum, shasum -a 256, or Node's crypto.createHash('sha256') on the same file and get the identical digest. The control does not depend on trusting JAD's tooling.
Why does the evidence hash change if it was only opened and saved?
An .xlsx rewrites an internal Last-Modified timestamp on every save and may recompress the package, so the bytes — and the SHA-256 — change even with no value edits. Capture the baseline before anyone opens the file, and keep a sealed copy for the register.
Which digest is the integrity control value?
SHA-256. Record it as the control. SHA-512 is a higher-assurance cross-check where policy requires it. SHA-1 and MD5 are emitted only for legacy interoperability and must not be used as the integrity control.
How do I share evidence externally without leaking internal metadata?
Wipe document properties (author, paths) with the Application Metadata Wiper, then hash the sanitised copy as a separate evidence item. Register both digests and document the wipe so the byte difference between the internal and shared copies is explained.
What if the auditor's hash doesn't match my register?
The file changed between collection and review — likely a re-save, a corrupted transfer, or an unauthorised edit. Investigate the cause and run a value-level Range Diff against a sealed copy to see whether content actually changed or it was just a re-save.
Where should the baseline digest be stored?
Separate from the evidence file, in a write-once store or a system with its own immutable audit trail. If the hash lives in the same writable location as the file, an editor could rewrite both and defeat the control.
How large an evidence file can I hash for free?
Up to 5 MB per file on Free, one file per run. Row count is irrelevant because hashing is byte-only. Larger operational exports need Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
Are there options to configure before hashing?
No. There is no settings panel — the tool goes from upload straight to Process and always returns SHA-1, SHA-256, SHA-512, and MD5 over the whole file. There is no algorithm picker or per-sheet option.
Where is the hashing engine for this control?
This Excel entry point cross-links to the canonical Multi-Hash Fingerprinter, the shared engine that computes all four digests for any file. Both produce the identical SHA-256 because both hash the same raw bytes.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.