Auditing IAM Changes When the Provider Holds the Hypervisor
You are the lead auditor for an internal audit of a fintech's cloud environment. The firm runs 120 production workloads on a hyperscaler across three accounts. Management asserts that "the cloud provider's SOC 2 covers our controls." The provider's SOC 2 Type II report covers 12 months, but the audit period ended 8 months ago and the report is carve-out for data center physical security. You are granted read-only console access, but the provider does not permit access to hypervisor logs or the underlying host OS. API activity logs are available in the customer account, but the retention window is 90 days and the audit needs 12 months of evidence. The IAM team made 34 production changes last quarter under an emergency change process requiring only one approver. Sampling of 25 IAM changes found 4 without documented approval.
1. Assess whether the provider's SOC 2 report is sufficient evidence for the controls in scope.
Read the worked answer
No, and management's framing is the first finding. A provider's SOC 2 attests to the provider's controls, not the fintech's. It does not cover the fintech's IAM configuration, change management, logging, or data classification - which is where the audit risk sits. Invoking it as blanket coverage is a misunderstanding of the shared responsibility model.
Specific deficiencies:
- Staleness: the report period ended eight months ago. Roughly 40% of the audit window has no coverage. A bridge letter or the provider's next report is required; otherwise the gap must be documented as a limitation.
- Carve-out: physical security controls are excluded. As with any carve-out, the fintech must obtain the subservice organization's evidence or record the affected objectives as unverified.
- Complementary user entity controls (CUECs): the report lists controls the fintech must operate for the provider's assurances to hold - identity federation, key management, logging enablement. The auditor must map each CUEC to a tested fintech control. Untested CUECs are where cloud breaches actually occur.
Judgement: the SOC 2 is useful input for the provider layer and should be mapped into the control matrix, but it cannot substitute for testing the fintech's own configuration and change controls. Concluding otherwise would produce an opinion that is not supported by evidence.
2. How should the auditor respond to the restriction on hypervisor and host OS access?
Read the worked answer
Distinguish a scope limitation from a shared-responsibility boundary. The hypervisor and host OS are the provider's responsibility. The auditor has no right to that evidence and, in most public cloud models, cannot obtain it. Demanding it would misread the responsibility model and would not be resolved by the provider.
Instead, test the control objective with available evidence:
- The objective is typically "unauthorized access is prevented and detected." Evidence includes the provider's SOC 2 coverage of the virtualization layer, plus the fintech's own API activity logs, identity and access configurations, network flow logs, and configuration-drift alerts.
- Assess whether the fintech has enabled and monitored the logs it controls, and whether alerts are tuned and acted upon.
- Review the provider's attestations and the fintech's CUEC operation for the layers it does own.
When it becomes a real limitation: if the control objective cannot be evidenced by any available means - for example, if the fintech relies on a provider assurance that is stale and has no compensating monitoring - then the auditor should communicate the limitation to those charged with governance and consider a qualified conclusion for the affected area. The key is to document why the restriction is or is not material, rather than treating it as automatically fatal or automatically acceptable.
3. Evaluate the IAM sampling results and the 90-day log retention. What deficiency conclusions follow?
Read the worked answer
Sampling: 4 deviations in 25 items is a 16% deviation rate. Unless the tolerable rate was set unusually high, the upper deviation limit will exceed it, and the control cannot be concluded effective. Expanding the sample is unlikely to rescue a 16% error rate; the better course is to conclude the control is not operating effectively, identify the root cause, and test compensating detective controls.
Root cause to investigate: the emergency change process permits a single approver for production IAM changes - the most privileged changes in the environment. Emergency access should be exceptional, logged, reviewed retrospectively, and time-bound. Thirty-four uses in a quarter suggests the emergency path has become the normal path. That is a design deficiency, not just an operating one.
Log retention: 90 days of API activity logs against a 12-month evidence requirement means 75% of the audit period cannot be tested. This is an evidence gap the fintech controls and can fix. Recommend retention aligned to the audit and regulatory horizon, immutable storage, and documented log-integrity controls.
Reporting: raise two deficiencies - change management (design and operating) and logging/evidence retention - with severity ratings tied to impact, and note that both are the fintech's responsibility, not the provider's. Include management's remediation owners and dates, and schedule follow-up testing of the compensating detective controls.