When an evidence connection breaks during an audit period, restore it first, then export what the source system still holds for the missing days, label that export with its true date, write a short note describing the gap, and tell your auditor early. Never backdate records or hide the gap.
TL;DR: Gaps happen. Tokens expire, staff leave, and vendors change their interfaces. What matters is how fast you notice, how honestly you record it, and how well you explain it. This guide gives a six step recovery plan, a table of backfill options, and an invented example of an eleven day gap handled well.
Definition box. An evidence gap is a stretch of time inside the audit period when a control may have been running but your records do not prove it, usually because the system that collects the records stopped working.
What counts as a broken connection?
Compliance tools read your systems through connections. A connection might use a key (called a token), a login, or a permission granted by an admin. When it stops working, the tool can no longer collect new records from that system.
Common reasons include:
- The token reached its end date. GitHub's documentation recommends giving personal access tokens an expiration, and notes that tokens not used for a year are removed automatically.
- The person who set up the connection left the company, and their account was closed.
- An admin changed a permission or turned on a new security setting.
- The source system changed how it answers requests, or had an outage.
The result is the same in each case. For some days, the tool saw nothing, or showed errors. Our post on automated evidence versus a connection record explains why a working connection and real evidence are different things, and why it matters to notice the difference.
Why does a gap matter to an auditor?
Auditors look at a window of time. They want to see that your controls ran across the whole window, not just on a few dates. A gap in your records raises a question: did the control stop, or did only the recording stop?
The answer can usually be found. If the source system still holds its own logs, you can often show the control kept running. If it does not, you may need another kind of proof, such as a ticket trail or a manager's note. In either case, a clear and honest explanation gets you most of the way. What damages trust is a gap that was hidden or papered over.
What are the six recovery steps?
- Confirm the scope of the gap. Find the date of the last good record and the date the connection was restored or will be. Count the days. Check which tests and which evidence were affected, not only the one that raised the alarm.
- Restore the connection safely. Create a new connection with the smallest permission that works, owned by a shared service account rather than a person. Set an expiration you can track, and put a reminder in a shared calendar two weeks before it. See the read-only access checklist.
- Backfill from the source. Ask whether the source system still has the records for the missing days. Many do, for a limited time. Export them right away, because the window to export may be closing. Use the table below.
- Label the backfill honestly. The export gets the date you actually made it, plus a note saying which dates it covers. Never edit dates inside files to make them look as if the tool collected them in real time.
- Write the gap note. Record what broke, when you noticed, how long it lasted, what you did, and what evidence covers the gap. Keep it to a paragraph or two.
- Tell your auditor. Share the note before they find the gap. Ask whether the backfill is acceptable for their work. They decide, not you.
What backfill options might exist?
What you can recover depends on the system. Here are common patterns. Always check the current documentation for your own systems, because retention changes.
| Source type | Possible backfill | Watch out for |
|---|---|---|
| Code host with an audit log | Export events for the missing dates | Logs may only be kept for a limited time. GitHub documents 180 days for organization audit logs, viewable by owners |
| Code host change history | Merged changes and approvals stay in the repository history | History shows what merged, not every setting that was on each day |
| Identity system | Sign-in and account change logs for a limited period | Check how many days your plan keeps |
| Ticket tracker | Tickets keep their own created and closed dates | Dates inside tickets can be edited by some users |
| Manual controls (reviews, sign-offs) | Not affected by the tool | Make sure the review itself happened on time |
If no source holds the missing records, say so in the note. A truthful "we cannot recover this" is better than an invented record. You can often add a different kind of evidence, such as a signed manager statement describing what was done, as long as it is clearly marked as written after the fact.
A worked example with invented numbers
The numbers below are invented for illustration.
A twelve person company is in the third month of a six month audit period. On the morning of March 14, the operations lead sees seven tests marked "error" for the code host. The last good record was March 3. That is an eleven day gap.
She follows the steps.
- Scope: Seven tests depend on the code host. No other system was affected.
- Restore: The engineer who created the connection used a personal token with a 90 day end date. He replaces it with a fine-grained, read-only token owned by a shared service account, sets a new 60 day expiration, and adds a calendar reminder for day 45.
- Backfill: The organization audit log still holds all eleven days, since it keeps events for 180 days. An owner exports the events as a file and saves it on March 14. The merged changes for those days are also exported from the repository.
- Label: The folder holds a file named with the March 14 export date, and the register row notes "covers March 3 to March 14."
- Note: One paragraph: token expired on March 3, noticed on March 14 after seven tests errored, restored same day, 11 days backfilled from the organization audit log, 19 merged changes in that period, all with a second approver.
- Auditor: The note goes to the audit team the same afternoon.
Total effort was about two hours. The gap in automatic collection is real, but the story is complete. Had the company waited six months to notice, the log retention window might have closed and the backfill would not have been possible.
How do you prevent the next gap?
- Monitor the monitors. Set an alert for any test in "error" or "unknown" state for more than a day.
- Track every connection in your register with its owner, permission level, and expiration.
- Avoid personal accounts for integrations. People leave. Service accounts stay.
- Review connections quarterly as part of your normal access review. See access review evidence.
- Keep a small manual routine as a backstop, such as a monthly export, as in starting to collect evidence before you buy a tool.
Where does Safeguard fit?
Safeguard's compliance and evidence automation keeps dated results so you can see exactly when a check last ran and when it resumed. Its dependency scanning and SBOM (software bill of materials, a list of the parts inside your software) records add dated snapshots on the software side. You can try a free scan at gold.safeguard.sh/scan. Your auditor, not any tool, decides whether a backfill is acceptable.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the demo and notice how continuous checks build a timeline. Picture where a gap in that timeline would appear, and what you would need to explain it.
Quick check
Do I have to tell the auditor about a short gap?
It is wise to. A short gap with a clear note usually causes little trouble. A gap the auditor finds on their own can raise doubts about the rest of your records.
Can I just re-date the exported file to match the missing days?
No. Label the file with the date you really exported it and note which dates it covers. Changing dates is backdating, and it can undermine all your evidence.
What if the source system no longer has the old records?
Say so in your note. Offer other evidence, such as tickets or a dated statement from the control owner, clearly marked as written later. The auditor decides what is acceptable.
Sources
- Managing your personal access tokens, GitHub Docs
- Reviewing the audit log for your organization, GitHub Docs
Last reviewed: 19 October 2026.