State what events you log, where logs are stored and protected, how long you retain them, who reviews them and what triggers an alert. Add whether customers can see their own tenant's activity. Specific answers end the thread. General claims such as "we monitor everything" start a new one.
What the questions usually are
- Do you log authentication events, administrative actions and data access?
- How long are logs kept?
- Are logs protected from tampering?
- Who reviews them, and how often?
- Do you alert on suspicious activity?
- Can we get logs for our tenant?
NIST's log management guidance describes the need for sound log management and gives practical guidance on building and maintaining log management practices across an enterprise. Its framing, infrastructure first, then process, is a good order for your answer.
A layered answer
1. Sources. List the log sources: application, authentication provider, cloud control plane, databases, network edge, and endpoint tooling where you have it.
2. Events captured. Sign-ins and failures, role changes, administrative actions, API calls with identity, configuration changes, and data export events.
3. Protection. Logs are shipped off the producing host to a store with restricted write access. State whether administrators of the source system can alter the store.
4. Retention. One number per class if they differ, for example security events versus debug logs. Mention that retention is a balance with privacy duties, since logs can contain personal data.
5. Review and alerting. Which conditions raise an alert, who is notified, and whether someone is on call. Be honest about hours. If nobody watches at night, say alerts page an on call engineer, if that is true, and describe the response expectation.
6. Customer access. Whether admins can view or export an audit log for their tenant, and how soon events appear.
Avoid these mistakes
- Claiming a security operations centre if you do not run one. Reviewers read that as a claim of staffed monitoring around the clock.
- Promising retention you cannot afford to keep.
- Listing a tool name instead of the control. The reviewer wants to know what you detect, not which product logs it.
- Forgetting that logs may hold personal data. State access limits.
Evidence to attach
| Item | Why it helps |
|---|---|
| Logging standard with review date | Shows a defined practice |
| Screenshot or export of retention settings | Backs the number |
| Sample alert rule list | Shows what is detected |
| Redacted audit log sample | Shows customer-facing detail |
For fields that make logs useful later, see audit log fields for AI security review decisions, and for the buyer's side, audit logs and roles: questions to ask a security vendor.
Link logging to incident response
Reviewers often move from logging to "how would you know you were breached." Show the chain: a detection source, an alert, a triage step, and an incident record. Keep the answer consistent with your incident response description.
Test your own answer
Pick a plausible event, such as an admin disabling MFA for a user, and trace it. Is it logged? Where? Who would see it? How long until? If you cannot answer in two minutes, fix that before a buyer asks.
Safeguard's compliance and evidence automation can collect dated records of this kind, which helps when a reviewer asks for proof.
Quick check
How long should we keep security logs?
It depends on your risk, contracts and privacy duties. State your actual figure and the reason. Do not copy a number you do not meet.
Do customers need access to raw logs?
Many want tenant level audit logs for sign-ins and admin actions. Raw infrastructure logs are usually not shared because they may include other tenants' data.
Sources
Last reviewed: 19 October 2026.
