Notifications
Clear all
Topic starter
07/06/2026 9:09 pm
TL;DR: Auditability depends on how well access, change history, and resource scope are made queryable, not on manual evidence chasing, according to StrongDM. StrongDM describes how its SOC 2 audit workflow used audit logs, point-in-time snapshots, RBAC listings, and tagged scopes to answer evidence requests, and says it successfully submitted 100% of requests.
NHIMG editorial — based on content published by StrongDM: Answering Auditors’ Questions in a SOC 2 Review
Questions worth separating out
Q: How should teams prepare identity evidence for a SOC 2 audit?
A: Teams should make access, role, and configuration history queryable before the audit starts.
Q: Why do tags matter in SOC 2 evidence collection?
A: Tags matter because auditors do not review your entire environment, only the systems in scope.
Q: What breaks when privilege data cannot be tied to time?
A: When privilege data has no reliable time dimension, teams cannot prove whether access existed before a change, during the review period, or after offboarding.
Practitioner guidance
- Build point-in-time audit queries for all privileged systems Make sure auditors can reconstruct who had access, what changed, and when, using preserved configuration history rather than manual screenshots or spreadsheet exports.
- Standardise resource tags for audit scoping Apply consistent tags such as production, finance, or regulated to users and resources so evidence queries can be filtered without guesswork or ad hoc mapping.
- Map production change rights to role listings Keep role and permission exports that show exactly which identities can promote or implement changes in in-scope environments at a given time.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step CLI commands for extracting audit history and configuration snapshots.
- Detailed examples of how to filter activity streams for infrastructure changes.
- Practical queries for identifying production users, roles, and admin permissions.
- Examples of how session logs and database query logs can support audit evidence.
👉 Read StrongDM's SOC 2 audit walkthrough for access and evidence collection →
SOC 2 evidence collection for NHI access controls: what teams need?
Explore further
08/06/2026 8:57 am
SOC 2 evidence readiness is really identity evidence readiness. When audit teams ask for infrastructure changes, privilege lists, and authentication settings, they are testing whether the organisation can explain access behaviour across time. That is an IAM governance question first and a compliance question second. The practical conclusion is that audit workflows should be designed around traceability, not manual testimony.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- A separate finding from the same research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why audit evidence often requires manual reconstruction.
A question worth separating out:
Q: How do teams reduce manual work in recurring audits?
A: They should move recurring evidence requests into systems that can be queried directly, such as audit logs, filtered exports, and replayable session records. The more the evidence process depends on live querying of identity and activity data, the less it relies on ad hoc collection during the audit window.
👉 Read our full editorial: SOC 2 audit evidence and access controls for NHI programs
