Audit evidence is a record that shows a control operated: dated, produced by a system if possible, and tied to a named control and period. You can review, request and chase most of it from a phone. Do the collecting where the systems are, and use mobile for follow-up and approvals.
What counts as good evidence?
Auditors look for four things. The record is dated, so they can place it in the audit period. It comes from the system itself, such as a log export or a settings report, not a screenshot someone retyped. It names the control it supports. And it shows the control working: a review that was signed off, a change that was approved before deployment, a vulnerability that was fixed within your stated window.
Weak evidence is the opposite: undated, hand made, or showing only that a policy exists.
Where does a phone fit?
A phone is for the work between collection and submission. Examples: checking which evidence requests are still open, nudging an owner who has not uploaded, approving an access review, answering an auditor's quick question, and reading a summary before a meeting.
Safeguard's mobile app for iOS and Android is early access beta. We do not describe its screens here, because they change during beta. The general idea is that the same answers from the platform are available on a phone. The compliance work itself, such as mapping frameworks, collecting evidence and monitoring controls, lives in the Safeguard web app at app.safeguard.sh, which you can also drive through chat.
A weekly routine
Run the same short cycle every week and the audit month becomes quiet.
Monday, review the gaps. List controls whose evidence is missing or older than your refresh window.
Midweek, chase owners. Send each owner a list of exactly what is needed, by when, and where to put it.
Friday, spot check. Open three random evidence items and ask whether a stranger could tell what control they support and when they were produced.
Who should own which piece?
Give every control one named owner and one reviewer. The owner produces the evidence. The reviewer checks that it is dated, complete and attached to the right control before it goes to the auditor. Splitting the two catches most errors early, and a phone is a fine place for the reviewer to confirm and approve while the owner works in the source system.
What commonly goes wrong?
Evidence arrives in the wrong period. The review was done but not dated. A screenshot shows a setting but not which system or account. A sample is requested and the underlying population cannot be produced. Fix these by agreeing naming, dating and storage rules before the audit starts.
How does supply chain evidence fit?
If your framework asks about development and third-party components, keep a dependency inventory per release, scan results with dates, the record of how critical findings were handled, and the settings that enforce review on code changes. Generate them from the tools, not by hand.
Open the full framework mapping demo
What to do
- Create one list of controls with owner, evidence source and refresh date.
- Prefer exports and system reports over manual screenshots.
- Name files with control, system and date so any reviewer can place them.
- Run the weekly cycle above, starting four to six weeks before fieldwork.
- Use your phone for approvals and nudges, and the full web app for collection and mapping.
- Ask your auditor early about sampling and population requests.
Quick check
Is the Safeguard mobile app generally available?
It is early access beta. Check the Safeguard download page for current status.
Does using a tool make us audit ready?
No. A tool collects and organises evidence. Controls still have to operate, and an auditor decides whether they are effective.
Sources
Last reviewed: 18 October 2026.
