What ITGC testing actually asks for
An ITGC walkthrough is less about whether a control exists and more about whether you can show it operated throughout the period. Auditors sample. They want the population, the evidence for the sampled items, and confidence that the population is complete. That last part is where most infrastructure teams lose time.
The uncomfortable version of the question is: prove this control was working in March. Screenshots taken in October do not answer it. A continuous, timestamped record does, and it also answers the follow-up about what happened on the days it was not.
Logical access
The evidence a host agent can supply: local accounts and group membership, changes to passwd, group and shadow, sudoers and privileged account configuration, setuid binaries and file capabilities, and SSH authentication events including failures, sources and authentication method.
What it cannot supply: whether access was approved, whether the approver was the right person, whether the quarterly user access review actually happened, and whether duties are segregated in a way that makes sense for your organisation. Those are the controls auditors care most about and no agent observes any of them. SecAI reports them as manual verification required.
Change management
File integrity monitoring on sensitive system paths detects that a change happened, when, and to what. That is genuinely useful as a completeness check: it can surface changes that never appeared in the change record, which is the thing a sampling-based test is least likely to catch.
What it is not is evidence of change authorisation. Whether a change was raised, reviewed, approved and tested lives in your change system, not on the server. SecAI evidences the detection half and reports the authorisation half as manual, rather than treating a detected change as an approved one.
IT operations
Monitoring coverage itself is evidence: which servers were actively reporting, and when each last reported, so a period where a system was unmonitored is visible rather than assumed away.
Backup and recovery is the notable gap. SecAI does not verify that backup jobs completed or that a restore succeeded, and a backup package being installed is not evidence that backups run. That control is reported as not assessed, because an unverified backup reported as satisfied is precisely the kind of finding that makes an auditor distrust everything else in the pack.
Security monitoring and audit trail reliability
Security event capture, the incident history with severity and timestamps, and the automated response actions taken are direct evidence that monitoring operated and that detections were acted on.
Audit trail reliability depends on time. If server clocks drift apart, the sequence of events across systems stops being trustworthy, which undermines every timeline built from those logs. SecAI observes whether each host clock is synchronised, which NTP implementation provides it and from which sources. It reports that control as partial rather than complete, because reliability also depends on log immutability and retention, which it does not verify on the host.
What this changes about the quarter
The realistic benefit is not that an assessment replaces your ITGC testing. It is that the technical population is already assembled and dated when the request arrives, instead of being reconstructed from memory and shell history under time pressure.
Each assessment is immutable and records the framework version and mapping version it ran against, so a report from Q1 still reads under the standard it was actually run against rather than being silently reinterpreted under a later one.