What Does Audit-Ready Mean? Record Integrity for Regulated Organizations

What is an audit-ready record?

A record is audit-ready when a reviewer who was not there can still check four things: what it says, who is responsible for it, when it was made, and whether the content is unchanged. ISO 15489-1:2016 sets out the concepts and principles behind creating, capturing and managing records. This guide turns them into four checks a reviewer can run: locatable, readable, attributable and demonstrably unchanged.

Auditors ask a narrower question. Under paragraph .08 of PCAOB AS 1105, the reliability of evidence depends on its nature and source and on the circumstances under which it is obtained.

Three terms recur through this guide. A hash is a short value calculated from a file's content, and it changes if the content changes. A signature ties a record to the party responsible for it. A timestamp fixes when a value existed. None of the three proves the record is correct.

Why does audit readiness matter for asset managers and fund administrators?

The cost of an undefined standard shows up during a review, not before it. An examiner asks for the record behind a NAV calculation or a trade allocation. The file exists, but nobody can show who signed it, or whether it was edited later. The question stays open until someone reconstructs the answer from email threads and system logs.

These gaps form long before the request arrives, through ordinary handoffs and re-saved files. The cost of data integrity failures in regulated finance lands later, as review time and disputed findings.

Funds that rely on administrators and other service providers carry a specific version of this problem. Under SEC Rule 31a-3, when others prepare or maintain a registered fund's required records on its behalf, the fund must obtain a written agreement that the records are its property and will be surrendered promptly on request. Advisers carry a parallel duty for their own electronic records: under Rule 204-2(g), they must be arranged and indexed for easy location, access and retrieval, and provided promptly when the SEC requests them. A record store that cannot meet that request on demand is not audit-ready, whatever else it does well.

A control that leaves no record is also a control nobody can test. For internal audit, the record is the only proof the control ran at all.

What do SEC examiners expect from supporting records?

Examiners ask whether a record can be produced, read and trusted without the person who created it standing next to it. For registered funds, Rule 31a-2 makes this concrete. Records kept on electronic storage media must be arranged and indexed so that any particular record can be easily located, accessed and retrieved. They must also be reasonably safeguarded from loss, alteration or destruction, with access limited to properly authorized personnel, the fund's directors and the SEC. Rule 204-2(g) sets comparable requirements for investment advisers.

That sets the minimum: the record can be found, survives intact and reaches only the people entitled to see it. A second layer sits on top: attribution. An examiner wants to know who is responsible for a NAV figure or an allocation decision, not simply that a document containing it exists somewhere.

Regulator-ready documentation meets both layers: it survives intact, and it names who stands behind it.

How do you prove a record hasn't been altered?

Proof, in this context, means something a stranger can check without trusting the person who hands over the file. A cryptographic hash algorithm reads a document's full content and returns a fixed-length digest, and identical content always gives an identical digest. NIST's Secure Hash Standard (FIPS 180-4) states that digests are used to detect whether messages have changed since the digests were generated. When today's digest matches the one recorded at approval, the content has not changed.

A digest alone does not say who approved the content, or when. A signature answers the first question by binding the digest to a party. A timestamp answers the second: under the Time-Stamp Protocol (IETF RFC 3161), a time-stamping service supports proof that a piece of data existed before a particular time.

US law sets a baseline for electronic form. Under the ESIGN Act, a signature, contract or other record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity or enforceability solely because it is in electronic form. Where a law requires a record to be retained, the Act accepts an electronic record that accurately reflects the information and remains accessible to the people entitled to it. None of this proves the content is true.

Used together, a hash, a signature and a timestamp are how you prove a document hasn't been altered: the hash shows the content is unchanged, the signature names who approved it, and the timestamp fixes when.

‍

‍

How does chain of custody work for a digital record?

Chain of custody is the account of who held a record, what they did to it, and when. For a digital file, it runs from creation to the moment a reviewer opens it, and covers where the file came from, every export or transfer, and the checks run at each step.

The chain breaks in ordinary ways. A valuation file gets emailed to the fund administrator and re-saved by the recipient. A spreadsheet gets copied into a new workbook. A PDF gets re-exported from a different application, which can change its internal structure even when the visible content looks the same.

Each step erases the link to the one before it. Keeping chain of custody for digital records intact therefore depends on a hash or signature that travels with the file through every transfer.

How do you share supporting records with auditors and regulators?

Sharing a record with an external reviewer raises a second problem: control. Once a file leaves a firm's systems by email or a shared link, the sender cannot limit who reads it, for how long, or in what form. Regulation S-P requires investment companies, broker-dealers and SEC-registered investment advisers to maintain written policies and procedures with administrative, technical and physical safeguards for customer information. Those safeguards must be reasonably designed to protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience. When a shared record contains customer information, the way it is shared belongs in that review as well.

Permissioned access addresses this directly. The sender decides, for each recipient, what is visible and for how long. NIST SP 800-53 Rev. 5 includes controls of this kind in its Access Control and Audit and Accountability families.

Secure data sharing with auditors and regulators rests on that model, together with a record of who opened which file, and when.

What should you prepare before an audit or exam starts?

Before a review opens, a firm should be able to produce three things: the underlying transaction and valuation records, the service-provider agreements that govern who holds which records, and the signature and timing evidence behind each. For registered funds, that includes the written agreements Rule 31a-3 requires. The ability to produce records promptly has to be built in advance, not assembled when the request arrives.

Treating preparation as a filing exercise produces a document on request. A reviewer also asks who is responsible for it and whether it changed since approval. An audit preparation checklist for regulated finance sorts these records by type, in the order reviewers typically ask for them.

What counts as compliance evidence, and how do digital asset rules change it?

Compliance evidence is the supporting record a firm keeps so someone outside the activity can test how it was carried out: the document, plus the trail of who created it and whether it changed afterward. A signed subscription agreement with no edit history is harder to test than the same agreement with a hash, a signature and a timestamp attached, even though both are technically "on file."

Regulation S-P adds a duty for incidents. The written policies it requires must include a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information, including customer notification procedures. A program like that can only be tested if its steps leave records.

Digital assets add further obligations, the record-keeping obligations behind digital asset compliance. Managers with EU-facing digital asset activity meet one of the most specific ones. Under Article 75(2) of MiCA, a crypto-asset service provider providing custody and administration of crypto-assets on behalf of clients keeps a register of positions, opened in the name of each client, corresponding to each client's rights to those assets.

How do you get there?

1. Define what "audit-ready" means for each record type your firm holds, using the four checks: locatable, readable, attributable and demonstrably unchanged.
2. Bind each record to a hash at the moment it is finalized, so later comparison has a fixed reference point.
3. Attach a signature that identifies the responsible party, and a timestamp that fixes when the hash existed.
4. Keep the history in a form that adds new entries instead of overwriting old ones, so a reviewer can see what changed and when.
5. Set permissioned access per recipient before a request arrives, rather than deciding sharing terms under time pressure.

How does an audit trail differ from an audit log and a tamper-evident record?

An audit trail lays out the sequence of actions that produced a record: who acted, and in what order. An audit log captures system-level events; NIST SP 800-92 treats log management as a computer security practice, not as a way to answer a reviewer's question. A tamper-evident record carries a mechanism, usually a hash, that reveals alteration after the fact rather than preventing it.

SEC rules show what a regulator means by an audit trail. For broker-dealers that keep records electronically, Rule 17a-4(f) accepts a complete time-stamped audit trail. That trail covers all modifications and deletions, the date and time of each action and, if applicable, the identity of the individual who took it. The alternative the rule offers is storage in a non-rewriteable, non-erasable format.

‍

A system that produces only logs can leave a reviewer unable to establish who is responsible for a record. That gap is the practical difference between an audit trail, an audit log and a tamper-evident record.

What are the common mistakes with audit readiness?

Treating storage as the finish line. A file that has sat untouched in a shared drive for years is stored, not audit-ready. Storage says nothing about who is responsible for it, or whether it changed.

Checking file metadata instead of content. Creation and modification dates in file properties can be edited in seconds. They are not evidence that the content is unchanged.

Calling a mechanism "immutable" when it is tamper-evident. A hash mismatch does not prevent an edit, it reveals one. Overstating what a control does is its own compliance risk.

Keeping the proof in the same place as the file. If the recorded hash lives in a folder the same person controls, a reviewer still has to trust that folder.

Preparing only after the request arrives. Access, history and attribution have to exist before the question is asked. They cannot be reconstructed under a deadline.

Where Filedgr fits

On the four checks above, storage answers only the first two. Two questions stay open: who is responsible for a record, and whether its content changed. Filedgr provides verification infrastructure for that gap, so a recipient can check a record without relying on the sender's word.

A record is captured with its context and held in a Filedgr Vault, with permissions set per recipient, together with the hash, signature and timestamp that make its integrity demonstrable. Proof Packages bundle a file with those elements, so a recipient can verify it even outside Filedgr.

Since June 2026, the public Filedgr Explorer lets any third party check a record's signature and blockchain transaction without a Filedgr account, and without seeing the content behind it.

Filedgr does not decide whether a record meets a regulation, calculate or audit a value, or replace an audit. It keeps the supporting record attributable, controlled and verifiable, so those judgments have something solid to work from.