Auditing a cloud or SaaS vendor is not a matter of collecting a SOC report, confirming that the provider has a security certification, and closing the workpaper. The customer still owns business risk, data obligations, user access, configuration choices, integrations, and many control activities that the provider cannot perform on its behalf.
The current ISACA CISA scope includes cloud and virtualized environments, vendor selection and contract management, and supply-chain risk. A defensible audit therefore traces the complete service relationship: what the provider does, what the customer must do, what subcontractors do, and what happens when any of those responsibilities fail.
Define the service boundary and criticality first
Start with the business service, not the vendor’s control catalog. Identify the processes supported, data processed, integrations, user groups, privileged roles, regulatory obligations, geographic requirements, recovery expectations, and consequences of unavailability or data loss. A low-risk collaboration tool should not receive the same audit depth as a service processing payroll, payment data, clinical records, or production credentials.
Map the technical boundary. Determine whether the provider hosts only the application or also identity, encryption keys, backups, network controls, logging, and administrative support. Identify customer-managed connectors, local agents, API tokens, data exports, single sign-on, mobile access, and downstream systems that extend the risk beyond the vendor’s hosted platform.
Criticality determines evidence. For an important service, auditors may need architecture diagrams, data-flow records, recovery commitments, penetration-test summaries, security incident history, access-control evidence, and contract terms in addition to third-party assurance reports.
Translate shared responsibility into a control matrix
Shared responsibility becomes auditable when each control has an owner. Create a matrix for identity, privileged administration, configuration, encryption, key management, logging, monitoring, vulnerability management, secure development, backups, recovery, incident response, retention, deletion, and privacy obligations. Mark whether each activity is provider-owned, customer-owned, jointly operated, or delegated to another party.
A common failure is to treat a provider feature as an operating control. Multi-factor authentication may be available, but the customer still has to enable it for the right users, manage break-glass accounts, remove stale access, and monitor privileged changes. Encryption may be built in, but key ownership and data classification can remain customer decisions.
The audit should test the customer’s side of the model with the same seriousness as the provider’s. Misconfiguration, excessive permissions, unmanaged service accounts, insecure API integrations, and disabled logging can defeat strong provider controls.
Use SOC and certification reports as evidence, not conclusions
Third-party assurance reports can reduce duplicated work, but only when the scope matches the service and risks under review. Check the exact legal entity, product, region, infrastructure, control period, and system boundaries covered. A report for one cloud service does not automatically cover every product sold by the same company.
Read the auditor’s opinion, exceptions, subservice-organization treatment, complementary user entity controls, and period of coverage. Complementary user entity controls are especially important because they tell the customer what it must operate for the provider’s control framework to achieve its objectives.
Bridge letters can help address a gap between the report period and the audit date, but they are management representations, not replacements for independent testing. Significant incidents, platform changes, acquisitions, new regions, or control exceptions may require additional evidence beyond the annual report.
Audit contract language against operational reality
Contracts convert risk decisions into enforceable expectations. Review security obligations, incident-notification timing, breach cooperation, right-to-audit clauses, data ownership, confidentiality, subprocessor terms, service levels, recovery commitments, insurance, regulatory support, retention, deletion, and termination assistance.
A contract can be strong on paper and weak in practice. Compare promised response times to actual tickets, recovery objectives to test evidence, deletion commitments to technical workflows, and notification requirements to past incidents. If the agreement requires customer approval for subprocessors, verify how changes are communicated and approved.
Look for ambiguity around data created by the service, including telemetry, derived analytics, model training data, backups, and support snapshots. The customer should know what information the provider retains, for how long, in which locations, and under what legal basis.
Test identity, configuration, logging, and change controls
Many SaaS audit findings arise in tenant configuration rather than the vendor’s core infrastructure. Review federated identity, MFA, role design, administrator count, privileged access, dormant accounts, joiner-mover-leaver processes, guest users, API credentials, and emergency access. Reconcile users to authoritative HR or identity sources where possible.
Configuration baselines should cover security-relevant settings such as external sharing, public links, session duration, data export, API access, retention, encryption options, audit logging, and administrative alerts. Determine who can change those settings and whether high-risk changes are logged and reviewed.
Logging must support the customer’s investigation needs. Confirm that audit logs contain the required events, are retained long enough, can be exported without losing context, and are integrated with monitoring or incident-response processes. If the provider controls retention, the contract and service tier should match regulatory and business requirements.
Follow data through privacy, residency, and deletion
Inventory the categories of data stored or processed by the service, including metadata and support information. Confirm approved purposes, data locations, cross-border transfers, residency commitments, encryption, retention, legal holds, and data-subject obligations where applicable.
Deletion deserves direct testing. Terminating a user account may not delete messages, backups, exported files, analytics, or retained support copies. Ask what “deleted” means technically, when deletion propagates to replicas and backups, and how the provider proves completion.
Cloud audits should also examine data portability. A customer that cannot retrieve usable data in a standard or documented format may face both operational and regulatory risk during migration or termination.
Extend the audit to subprocessors and supply-chain dependencies
The provider may depend on hyperscale cloud platforms, payment processors, identity services, content-delivery networks, support contractors, AI services, and other subprocessors. These dependencies can create concentration, security, privacy, and availability risks that are not obvious from the primary contract.
Current ISACA CRISC coverage explicitly includes vendor and supply-chain risk management. For audit purposes, determine which dependencies are critical, how the provider assesses them, whether incidents flow through the notification chain, and whether the customer has visibility into material changes.
Concentration matters when many critical services depend on the same infrastructure or identity provider. An enterprise can diversify application vendors while still holding a single underlying cloud or authentication dependency. Include that systemic exposure in risk reporting.
Vendor governance should also consider organizational and financial change. Acquisitions, layoffs, product divestitures, data-center migrations, changes in support model, or aggressive price restructuring can affect service quality and control ownership even when the security certification remains valid. Review how the organization receives and evaluates material-change notifications.
For critical vendors, sample actual operational evidence rather than relying only on policies. Trace a recent privileged-access request, security incident notification, backup restore, user termination, configuration change, and support escalation from initiation through closure. These samples show whether the contractual control model works in daily operations.
Finally, distinguish vendor failure from customer governance failure. If the provider offered a required control but the customer never enabled it, the risk belongs largely on the customer side. If the provider failed to meet a contractual commitment, the response may involve remediation, credits, escalation, compensating controls, or replacement. Audit reporting should make that accountability visible.
Service-level metrics need interpretation as well. A provider can meet a monthly uptime percentage while a short outage occurs during the customer’s most critical processing window. Review the definition of availability, excluded maintenance, measurement points, service credits, and whether the contract distinguishes core functionality from peripheral features.
Security questionnaires can support due diligence, but answers should be risk weighted and verified for critical services. High-value evidence includes configuration screenshots tied to the customer’s tenant, test results, audit logs, recovery evidence, ticket records, policy exceptions, and independent reports. The purpose is not to collect the largest evidence package; it is to establish whether the control claims that matter to the customer are supported.
Audit scope should include the customer’s vendor-management process too. Determine whether risk classification is refreshed, assurance reports are reviewed promptly, findings are tracked to closure, contracts are renewed with updated requirements, and business owners remain accountable after procurement hands the service into operations.
Renewal is another control point. Before a critical service is renewed, reassess changes in scope, data, subprocessors, incidents, assurance findings, recovery performance, and business dependence. Automatic commercial renewal should not become automatic risk acceptance.
Audit resilience and exit before a crisis forces the test
Review recovery objectives, backup architecture, failover design, resilience testing, incident communications, and customer responsibilities during an outage. Do not rely only on published uptime. Ask whether the service has tested regional failure, identity outages, ransomware scenarios, corrupted data, and dependency failures that resemble the organization’s actual risk profile.
Exit planning should cover data export, configuration records, encryption keys, logs, interface dependencies, user migration, parallel operation, contract termination, secure deletion, and knowledge transfer. Test whether the organization can leave the provider within a realistic time frame rather than accepting a policy statement that an exit plan exists.
Cloud-vendor assurance cuts across several ISACA certifications because the risk sits at the boundary between governance, audit, contracts, technology, and operations. Certifications and SOC reports are useful inputs, but the conclusion should still answer the harder question: does the combined provider-customer control environment manage the service’s real business, security, privacy, continuity, and exit risks?