Tell your auditor, decide whether the new service is in scope, and bring it under your existing controls from its launch date, not from the date you noticed. Keep evidence of onboarding, such as repository rules, scanning, access setup and logging, with real dates.
Why timing matters
Most audit reports with an observation window test controls across a period. A system added halfway through is only subject to controls for the time it existed, but it is subject to them for all of that time. If your change review rule applies to every production repository, the new repo must have had it from its first commit to production.
Step by step
- Record the launch date and what the service does with customer data.
- Tell the auditor early. Ask whether it is in scope and whether the system description needs updating.
- Walk the control list and mark which controls apply to the new service.
- Apply them before production traffic if you can. Otherwise note the gap period.
- Collect onboarding evidence and file it with dates.
- Add the service to the inventory that your sampling lists are drawn from.
An onboarding checklist for engineers
| Control area | What to set up | Evidence |
|---|---|---|
| Source control | Branch protection, code owners, required checks | Settings export, dated |
| Access | Roles through SSO groups, no shared accounts | Group membership export |
| Logging | Audit and application logs routed to central store | Config plus a sample event |
| Vulnerability management | Dependency and image scanning enabled | First scan result |
| Backups | Schedule configured, first restore test planned | Backup config, test ticket |
| Change management | Deploys go through the standard pipeline | First deployment record |
| Inventory | Service listed with owner and data class | Inventory entry with date |
The inventory is the root of sampling
Auditors draw samples from your lists of users, changes and systems. If the new service is missing from the inventory, it is missing from the population, and that is a completeness problem. See how auditors sample evidence for how populations and samples work.
When the service is a pilot
Pilots that touch real customer data count. Pilots that use synthetic data in an isolated environment may not. Write down which one it is and why, and have your auditor agree.
What if a control could not apply on day one
Say so. Document the compensating step, such as manual review until the pipeline rule is in place, and the date the gap closed. This is the same discipline as handling any exception.
A habit that prevents surprises
Add a launch checklist to your release process so new services cannot go live without the inventory entry and control setup. Make the checklist itself produce the evidence.
Quick check
Do I need to tell the auditor about every new service?
Tell them about services that handle in-scope data or change the system description. When unsure, ask.
Does the new service need its own narrative?
Usually not, if it inherits existing controls. Note the scope in the existing narratives.
Safeguard asset discovery and compliance automation can help keep the inventory current as services appear. Try a free scan.
Last reviewed: 19 October 2026.
