ABCDEFGHIJKLMNOPQRSTUVWXYZAAABAC
1
Cloud Audit Checklist for Chevy Health Tech Solutions
2
Control IDControl AreasControl ObjectivesCloud Security Alliance Cloud Controls Matrix (CCM) v4.1.0 ReferenceAudit QuestionsResponseFindingsCompliant/Non-CompliantRecommendations
3
1
Logging and Monitoring
4
1.1Logging and MonitoringEnsure all access to PHI is logged for audit and forensic purposes.LOG-07Are authentication events, privileged activities, API calls, and PHI access captured in centralized logs?
Yes, CloudTrail, VPC Flow Logs, and RDS audit logs are enabled and shipped to a centralized S3 bucket.
Comprehensive logging is in place for key security events and PHI access.CompliantCompliant
5
1.2Logging and MonitoringGuarantee log integrity and prevent tampering by unauthorized actors.LOG-04Are logs stored immutably with access restricted and logged, and segregated from system admin roles?
Yes, logs are in an immutable S3 bucket. Access requires MFA and is logged separately. Admin roles cannot modify logs.
Strong technical controls ensure log integrity and accountability.CompliantCompliant
6
1.3Logging and MonitoringEnsure high-risk events are identified and acted upon promptly.LOG-05Are automated alerts configured for anomalous PHI access patterns and high-risk events, with documented incident tickets generated?We have basic GuardDuty alerts, but no specific alerts for anomalous PHI access. Incidents are not auto-ticketed.Detection of PHI-specific threats is immature, relying on manual log review.Non-Compliant1. Develop and deploy custom anomaly detection rules focused on PHI access patterns (e.g., unusual volume, off-hours access).

2. Integrate security alerts with a ticketing system (e.g., Jira) to automatically create and assign incident tickets.

3. Define and document SLAs for triaging and responding to different alert types.
7
8
2
Cryptography and Key Management
9
2.1Cryptography and Key ManagementProtect patient data from exposure during transmission.CEK-03Is TLS 1.2 or higher enforced for all data in transit, including internal service-to-service communication?Yes, we enforce TLS 1.2 for all external endpoints and use AWS Certificate Manager. Internal traffic within the VPC is also encrypted.
Data in transit is consistently protected with strong encryption protocols.CompliantCompliant
10
2.2Cryptography and Key ManagementEnsure weak encryption algorithms are not in use.CEK-04Are weak or deprecated encryption algorithms and protocols (e.g., SSLv3, TLS 1.0) explicitly disabled across all cloud services and applications?We have disabled SSLv3 and TLS 1.0 on our load balancers. We are unsure about all legacy application configurations.Potential use of deprecated protocols in legacy apps creates an encryption risk.Non-Compliant1. Conduct a comprehensive scan of all applications and endpoints to identify any use of deprecated protocols.

2. Create a remediation plan to upgrade or reconfigure any systems found using weak protocols.

3. Implement a technical control (e.g., WAF policy) to block requests using deprecated TLS versions.

11
2.3Cryptography and Key ManagementMaintain control over keys protecting PHI through a documented lifecycle.CEK-12Is there an automated, documented process for rotating customer-managed keys (CMKs) and securely revoking them if compromised?Key rotation is manual, done roughly annually. A key revocation process exists but hasn't been tested.Manual, untested key management processes introduce risk of operational failure or delayed response to compromise.Non-Compliant1. Enable automatic annual rotation for all CMKs in KMS.

2. Document and, in a non-production environment, test the key revocation and replacement procedure.

3. Implement logging and alerting for key rotation events and failures.
12
13
3
Data Security and Privacy
14
3.1Data Security and PrivacyEnsure PHI is logically separated from non-sensitive workloads.I&S-06Is PHI logically segregated within the cloud environment using separate VPCs, accounts, or resource tagging with strict access controls?
PHI data is stored in a dedicated AWS account with restrictive VPCs and SCPs. Non-prod workloads are in a separate account.Strong logical segregation is enforced between PHI and non-sensitive environments.CompliantCompliant
15
3.2Data Security and PrivacyVerify compliance with Nigeria's NDPA data residency requirements.DSP-19Are technical controls (e.g., SCPs, region restrictions) in place to prevent storage or processing of PHI outside approved geographic boundaries?
Yes, SCPs deny API calls to create resources in disallowed regions for the PHI account.Technical controls are effectively enforcing data residency policy.CompliantCompliant
16
3.3Data Security and PrivacyProtect production PHI from unauthorized use in lower environments.DSP-15Is production PHI prohibited from non-production environments, with masking or anonymization used when test data is required?No formal prohibition. Developers sometimes use anonymized subsets, but it's not enforced. A recent audit found a staging DB with real PHI.Use of real PHI in non-production environments creates a significant data leakage risk.Non-Compliant1. Create and enforce a policy blocking production-to-non-production data replication via IAM and SCPs.

2. Implement and mandate the use of automated data masking tools to generate realistic, safe test data.

3. Conduct quarterly scans of non-production environments to detect and report any PHI spillage.
17
18
4
Cloud Service Provider (CSP) Assessment
19
4.1CSP AssessmentVerify the CSP's controls for securing PHI are independently audited.A&A-02Do we annually review independent audit reports (e.g., SOC 2 Type II) from the CSP covering security, availability, and confidentiality?We have not requested or reviewed these reports. We rely on the CSP's marketing materials.Relying on marketing claims instead of audited evidence creates a significant, unmanaged risk.Non-Compliant1. Request the CSP's latest SOC 2 Type II report (or equivalent) from their security portal.

2. Review the report's opinion and any exceptions, particularly for controls related to data protection.

3. Establish an annual cadence for reviewing these reports to ensure ongoing compliance.
20
4.2CSP AssessmentConfirm our understanding of security responsibilities under the shared model.STA-05Is the Shared Security Responsibility Model (SSRM) for our specific cloud services documented and understood by both security and engineering teams?We have a high-level understanding, but it's not formally documented. Engineers sometimes assume the CSP secures more than they do.Unclear SSRM leads to potential security gaps where neither party implements a required control.Non-Compliant1. Formally document the SSRM for each cloud service we use, clearly delineating CSP vs. Chevy responsibilities.

2. Conduct training sessions for all relevant teams (security, dev, ops) on this documented model.
3. Reference the SSRM in architectural design reviews and change management processes.
21
4.3CSP AssessmentEnsure third-party access to our PHI is restricted and monitored.STA-10Is third-party access (e.g., support, consulting) to our cloud environment reviewed, restricted to least privilege, and logged?Third-party access is granted on a per-case basis via IAM roles, but there is no formal periodic review of their access rights.Without regular review, third-party access may accumulate, violating least privilege.Non-Compliant1. Implement a quarterly review process for all third-party IAM roles and users.

2. Configure access to automatically expire after a defined period (e.g., 90 days), requiring renewal.

3. Ensure all third-party access is logged and monitored for anomalous activity.
22
23
5
Vulnerability Management
24
5.1Vulnerability ManagementEnsure timely identification of vulnerabilities in all cloud assets.TVM-03Are automated vulnerability scans conducted at least monthly on all VMs, containers, and serverless functions?We scan EC2 and ECR weekly. Scanning for Lambda functions is not yet configured.Scanning gap for serverless components potentially hides vulnerabilities.Non-Compliant1. Enable vulnerability scanning for all Lambda functions.

2. Aggregate all scan findings into a single Security Hub dashboard.

3. Auto-create tickets for new 'Critical' or 'High' findings.
25
5.2Vulnerability ManagementFocus remediation efforts on the most critical risks first.TVM-09Are vulnerabilities prioritized for remediation based on risk (severity + asset criticality + exploitability)?We use CVSS scores but do not factor in asset criticality or exploitability. All 'Highs' are treated the same.CVSS-only prioritization can delay fixes for the most business-critical risks, like a PHI database.Non-Compliant1. Tag assets based on criticality (e.g., 'PHI-Critical', 'Internal').

2. Integrate tags into the vulnerability management workflow to automatically adjust priority scores.

3. Incorporate threat intelligence (e.g., EPSS) to prioritize vulnerabilities being actively exploited.

26
5.3Vulnerability ManagementDetect and correct configuration drift from secure baselines.CCC-07Is there automated monitoring and alerting for configuration drift from approved security baselines (e.g., CIS benchmarks)?We use AWS Config, but only for a few basic rules. We don't have comprehensive monitoring against full CIS benchmarks.Configuration drift is largely undetected, potentially weakening the security posture over time.Non-Compliant1. Implement AWS Security Hub with CIS benchmarks enabled to continuously monitor for drift.

2. Configure automated remediation (e.g., via Systems Manager) for non-critical drift.

3. Establish a process to review and approve any necessary deviations from the baseline.
27
28
6
Network Security
29
6.1Network SecurityEnsure network segmentation isolates PHI systems from other workloads.I&S-06Are strict, least-privilege security group rules enforced between application tiers and environments to isolate PHI?PHI data is in a separate account. However, some security groups within that account are overly permissive (e.g., allow all traffic from web to DB).Overly permissive internal rules increase lateral movement risk to PHI within the trusted account.Non-Compliant1. Audit all security group rules in the PHI account, documenting business justification.

2. Refactor rules to be as specific as possible (e.g., web to app on port 8080, app to DB on 3306).

3. Use tools like Reachability Analyzer to regularly validate intended paths.
30
6.2Network SecurityProtect public-facing applications and APIs from web-based attacks.I&S-09Is a Web Application Firewall (WAF) deployed in front of all internet-facing applications with managed rule sets?Yes, AWS WAF with the core rule set protects all public APIs and web apps. WAF logs are monitored.
WAF is correctly deployed and managed to protect against OWASP Top 10.CompliantCompliant
31
6.3Network SecurityEnsure secure access to administrative interfaces.I&S-03Are all administrative interfaces (e.g., SSH, RDP) firewalled to allow access only from authorized, secured bastion hosts or VPN IPs?SSH access to EC2 instances is allowed from a bastion host in a protected subnet. Direct RDP to Windows instances is disabled.
Administrative access is securely managed via a bastion host.CompliantCompliant
32
33
7
Incident Response
34
7.1Incident ResponseEnsure the IR plan includes steps for NDPA-aligned breach notification.SEF-03Does the incident response plan include specific procedures for identifying the scope of a PHI breach and notifying affected patients and the NDPC within required timelines?The plan includes technical containment steps but lacks detailed notification procedures or templates for patients/regulators.Lack of notification procedures risks non-compliance with NDPA breach reporting timelines.Non-Compliant1. Update the IR plan with a "Breach Communication" annex, including NDPC contact details.

2. Develop pre-approved notification templates for patients and regulators.

3. Test these procedures in a tabletop exercise focused on a PHI breach scenario.
35
7.2Incident ResponseValidate the IR plan's effectiveness through regular testing.SEF-04Is the cloud-specific incident response plan tested at least annually through structured exercises like tabletops or game days?The plan has been discussed in a meeting but never formally tested.An untested IR plan is likely to fail during a real crisis.Non-Compliant1. Schedule and execute a tabletop exercise within 60 days, involving security, legal, and PR teams.

2. Based on lessons learned, update the plan and schedule a live technical simulation for the next year.

3. Document exercise results and track remediation of identified gaps.
36
7.3Incident ResponseEnsure post-incident learning leads to continuous improvement.SEF-09Is root cause analysis performed after significant incidents, with corrective actions tracked to completion?We do not have a formal RCA process. After incidents, we fix the immediate issue but don't track systemic fixes.Without RCA, the organization repeats the same mistakes, leaving underlying vulnerabilities unaddressed.Non-Compliant1. Establish a policy mandating RCA for all 'High' severity incidents.

2. Create a template to document findings, assign owners, and set due dates for corrective actions.

3. Review the status of corrective actions in monthly security meetings.
37
38
8
Patch Management
39
8.1Patch ManagementEnsure critical vulnerabilities in PHI systems are patched promptly.TVM-08Is there a documented patch management process with defined SLAs (e.g., Critical patches within 7 days) for all systems, especially those handling PHI?No formal policy. Critical patches are sometimes applied within weeks, depending on developer availability.Lack of formal patch SLAs leaves PHI systems vulnerable to known exploits for unacceptable periods.Non-Compliant1. Approve a patch policy with clear SLAs based on severity (e.g., Critical = 7 days, High = 30 days).

2. Implement automated patch deployment (e.g., AWS Systems Manager Patch Manager) to meet these SLAs.

3. Report on patch compliance against SLAs to management monthly.
40
8.2Patch ManagementEnsure patches are tested before production deployment to maintain availability.CCC-02Are patches tested in a production-like staging environment before being applied to production PHI systems?We rarely test OS patches in staging before production. We rely on the vendor's assurance.Untested patches risk instability and outages for critical health applications.Non-Compliant1. Ensure staging environment OS and app stack mirror production.

2. Mandate staging tests and validation for all patches before production approval.

3. Document test results as part of the change request.
41
8.3Patch ManagementEnable rapid response to critical zero-day vulnerabilities affecting PHI systems.CCC-08Is there an emergency change procedure for expedited deployment of critical security patches outside the normal change window?No emergency procedure exists. All changes must go through the standard change board.Lack of emergency process slows response to actively exploited vulnerabilities, directly risking patient data.Non-Compliant1. Create an "Emergency Security Patch" procedure with fast-track approval (e.g., CISO).

2. Define clear criteria for what constitutes an emergency (e.g., active exploit in the wild).

3. Test this process with a simulated zero-day patch drill.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100