Cloud Security Posture Assessment Checklist twelve sections that turn ad hoc cloud reviews into a defensible posture assessment artefact
A free, copy-ready cloud security posture assessment checklist. Twelve structured sections covering assessment header, identity and access posture, data protection and encryption posture, network and perimeter posture, workload and runtime posture, logging and monitoring and detection posture, vulnerability and patch posture, configuration baseline posture, third-party and supplier posture, resilience and backup posture, findings and exceptions and remediation routing, and the framework evidence pack and four-signature sign-off. Aligned with CSA Cloud Controls Matrix v4, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27001 Annex A, SOC 2 Trust Services Criteria, PCI DSS, NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Benchmarks for AWS, Azure, and GCP, AWS Well-Architected Security Pillar, Azure Security Benchmark, GCP Security Foundations Blueprint, NIS2 Article 21, and DORA Article 6 where the financial entity is in scope. Built for cloud security teams, AppSec teams, internal security teams, vulnerability management teams, GRC and compliance teams, security engineering teams, security operations leaders, CISOs, security architects, audit committees, and board risk committees that need a defensible alternative to ad hoc cloud console screenshot collection.
Run the cloud security posture assessment on the live workspace, not on a side spreadsheet
SecPortal pairs each assessment to a versioned engagement record so the in-scope cloud account list, the per-section named author and reviewer, the per-finding routing, the accepted-risk register, the framework evidence map, and the four-signature sign-off all live on one workspace with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn ad hoc cloud reviews into a defensible posture assessment artefact
A cloud security posture assessment checklist is the cross-account, cross-cloud review artefact that captures the security configuration, identity surface, data surface, network surface, workload surface, telemetry surface, vulnerability surface, configuration baseline surface, supplier surface, resilience surface, finding routing, and framework evidence posture of a cloud estate at a named point in time. The twelve sections below cover the durable shape of the assessment against CSA Cloud Controls Matrix v4, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27001 Annex A, SOC 2 Trust Services Criteria, PCI DSS, NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Benchmarks for AWS, Azure, and GCP, the AWS Well-Architected Security Pillar, Azure Security Benchmark, GCP Security Foundations Blueprint, NIS2 Article 21, and DORA Article 6 where the financial entity is in scope. Copy the sections that fit the estate and paste the rest as the estate grows.
The checklist is not the same artefact as the continuous CSPM stream. The CSPM stream answers what is misconfigured right now against the live cloud control plane. The checklist answers how the cloud security assessment actually operates against an audit, leadership, and customer set of expectations on a named cadence. The checklist is also not the same artefact as the operational lifecycle that walks each finding through to closure: pair the checklist with the CSPM finding remediation workflow for the per-finding lifecycle, the Kubernetes security finding remediation workflow for the per-cluster posture layer, the container image vulnerability remediation workflow for the workload-tier findings that compose with the cloud-account posture, the cloud security assessment use case for the broader programme view that the assessment fits inside, the audit evidence tracker for the per-control evidence ledger underneath the framework evidence map at Section 12, the security exception register template for the upstream document that holds the accepted-risk decisions from Section 11, the vulnerability management programme scorecard for the programme-level maturity read across the workload-vulnerability posture in Section 7, and the CSA Cloud Controls Matrix framework page for the canonical reference the framework evidence map at Section 12 anchors against.
Copy the full checklist (all twelve sections) as one block.
1. Assessment header, scope, and authority
Open the assessment artefact with the assessment identifier, the assessment window, the in-scope cloud accounts, the owner, and the framework obligations it evidences. A reviewer should be able to read in the first lines which assessment this is, who owns it, which cloud estate it covers, and which framework controls it is run against. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the assessment header is what makes the cloud security posture assessment evidence traceable across audit cycles rather than a loose folder of cloud console screenshots.
Assessment identifier (cross-referenced from the cloud security charter and the security testing programme record): {{ASSESSMENT_IDENTIFIER}}
Assessment title: {{ASSESSMENT_TITLE}}
Assessment window start date: {{ASSESSMENT_WINDOW_START}}
Assessment window end date: {{ASSESSMENT_WINDOW_END}}
Assessment cadence band (one of: quarterly regulated/high-criticality, semi-annual standard production, annual non-production/sandbox, event-driven re-assessment):
- {{ASSESSMENT_CADENCE_BAND}}
In-scope cloud estate (named accounts, subscriptions, projects, organisations):
- AWS account list with environment classification: {{AWS_ACCOUNT_LIST}}
- Azure subscription list with environment classification: {{AZURE_SUBSCRIPTION_LIST}}
- Google Cloud project list with environment classification: {{GCP_PROJECT_LIST}}
- Other cloud providers (Oracle Cloud, Alibaba Cloud, IBM Cloud, Tencent Cloud, OVH Cloud, Hetzner, DigitalOcean, Linode): {{OTHER_CLOUD_LIST}}
- Hybrid surface (on-premises components, colocation environments, SaaS tenants that materially extend the cloud trust boundary): {{HYBRID_SURFACE_LIST}}
Out-of-scope estate and the rationale (prevents scope drift): {{OUT_OF_SCOPE_LIST}}
Data classification anchor for the in-scope estate (named data classes mapped to cloud storage and processing services): {{DATA_CLASSIFICATION_ANCHOR}}
Assessment owner (the role accountable for the assessment artefact and outcomes):
- Role: {{ASSESSMENT_OWNER_ROLE}}
- Named person at time of publication: {{ASSESSMENT_OWNER_NAME}}
Section authors and reviewers (named engineer pool authorised to fill in and countersign each section):
- Cloud security engineer pool: {{CLOUD_SECURITY_ENGINEER_POOL}}
- Identity engineering reviewers: {{IDENTITY_ENGINEERING_REVIEWERS}}
- Platform engineering reviewers: {{PLATFORM_ENGINEERING_REVIEWERS}}
- AppSec engineering reviewers: {{APPSEC_REVIEWERS}}
- GRC reviewer: {{GRC_REVIEWER}}
Executive sign-off (the security operations leader, CISO, security director, or risk-committee chair who signs the artefact at publication):
- Role: {{EXECUTIVE_SIGN_OFF_ROLE}}
- Named person at time of publication: {{EXECUTIVE_SIGN_OFF_NAME}}
- Sign-off date: {{EXECUTIVE_SIGN_OFF_DATE}}
Framework expectations evidenced by the assessment (CSA CCM v4 IAM/DSI/IVS/GRM/SEF/BCR/AAC; ISO/IEC 27017 CLD controls; ISO/IEC 27018 if personal data is processed in the cloud; ISO/IEC 27001 Annex A 5.23, A 5.30, A 8.8, A 8.16, A 8.20, A 8.24; SOC 2 CC6/CC7/CC8/A1; PCI DSS Req 1/2/3/4/6/8/10/11/12 where cardholder data resides in the cloud; NIST SP 800-53 AC/AU/CA/CM/CP/IA/RA/SC/SI; NIST CSF 2.0 ID/PR/DE/RS/RC/GV; CIS Benchmarks AWS/Azure/GCP; AWS Well-Architected Security Pillar; Azure Security Benchmark; GCP Security Foundations Blueprint; NIS2 Article 21; DORA Article 6 where the financial entity is in scope; FedRAMP control baseline if the cloud workload supports a US federal customer; internal cloud security policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}
Cross-references:
- Cloud security charter: {{CLOUD_SECURITY_CHARTER_REFERENCE}}
- Security programme charter: {{SECURITY_PROGRAMME_CHARTER_REFERENCE}}
- Cloud security policy: {{CLOUD_SECURITY_POLICY_REFERENCE}}
- Vulnerability management policy: {{VULNERABILITY_MANAGEMENT_POLICY_REFERENCE}}
- Incident response plan: {{INCIDENT_RESPONSE_PLAN_REFERENCE}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: assessment version, effective date, trigger, author, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Identity and access management posture
Identity is the front door of every cloud estate. Capture the posture across root and break-glass accounts, privileged identity, human identity, workload identity, entitlement review, IAM policy hygiene, and access logging. The block reads against CIS AWS Benchmark Section 1, CIS Azure Benchmark Section 1, CIS GCP Benchmark Section 1, ISO 27001 Annex A 5.15 through A 5.18 and A 8.2 through A 8.5, NIST SP 800-53 IA and AC families, SOC 2 CC6, and PCI DSS Requirement 7 and Requirement 8.
Root and break-glass account posture:
[ ] Root account inventory across all in-scope accounts complete (AWS root user, Azure global administrator, GCP organisation owner)
[ ] Hardware MFA enforced on every root identity (record device serial or token reference)
[ ] Root account last used date audited (record date and rationale per account)
[ ] Break-glass account inventory documented with named human owner and storage of recovery factor
[ ] Break-glass account access events alerted in real time to the security operations leader
Privileged identity posture:
[ ] Named privileged roles inventoried per cloud (AWS administrator-equivalent roles, Azure Privileged Identity Management role list, GCP IAM owner/editor/security admin list)
[ ] Just-in-time elevation pathway in use for privileged role assignment (AWS IAM Identity Center session, Azure PIM activation, GCP IAM time-bound binding)
[ ] Standing privilege inventory documented with rationale (privileged identities with permanent privilege; each carries a named justification)
[ ] Hardware MFA enforced on every privileged human identity
[ ] Privileged session logging enabled and retained against the longest applicable framework
Human identity posture:
[ ] Single sign-on configured with named identity provider (Okta, Entra ID, Ping, Google Workspace, OneLogin, JumpCloud, Microsoft AD FS)
[ ] MFA enforced on all human identities at the IdP and the cloud federation entry point
[ ] Dormant account audit completed (90-day inactivity threshold; named disposition per identity)
[ ] Departed user audit completed (HR-to-IdP-to-cloud reconciliation; named time-to-deprovision metric)
[ ] Conditional access policies enforced (geo, device, sign-in risk, IP allowlist; named per IdP)
Workload identity posture:
[ ] Service principal, IAM role, and managed identity inventory complete (named purpose, named owner, last use audit)
[ ] Instance, pod, and function identities use cloud-native workload identity (IAM instance profile, GKE workload identity, Azure managed identity) rather than long-lived static credentials wherever feasible
[ ] Long-lived static credential inventory complete (named justification per credential, named rotation cadence)
[ ] External workload identity federation (GitHub Actions OIDC, GitLab CI OIDC, Terraform Cloud OIDC, Azure AD app registrations) inventoried and audited
[ ] Cross-account trust policy audit complete (named external principals, condition keys reviewed, public principal flag clear)
Entitlement review posture:
[ ] Named entitlement review cadence documented (quarterly default; semi-annual for low-criticality estates)
[ ] Last entitlement review date and reviewer recorded per scope
[ ] Privilege creep audit complete (identities whose privilege grew during the period are reviewed against role intent)
[ ] Cross-account access audit complete (named consumers of trust policies are still authorised)
IAM policy hygiene posture:
[ ] Custom IAM policy inventory complete (count, last review date, named owner)
[ ] Wildcard action audit complete (policies that grant Action: "*" or Resource: "*" carry a named justification)
[ ] Public principal audit complete (S3 bucket policy, KMS key policy, ECR repository policy, SQS/SNS topic policy, IAM trust policy)
[ ] Permissions boundary or guardrail policy posture documented (Service Control Policies, Azure Management Group policies, GCP organisation policies)
Access logging posture:
[ ] CloudTrail multi-region trail enabled on every AWS account with management events; data event logging enabled where required by data classification
[ ] Azure Activity Logs streaming to a centralised store on every subscription
[ ] GCP Cloud Audit Logs (Admin Activity, Data Access where applicable, System Event) streaming to a centralised store on every project
[ ] Log integrity verification enabled (CloudTrail log file integrity validation, immutable storage on centralised store)
[ ] Log retention configured against the longest applicable framework expectation
3. Data protection and encryption posture
Data is the asset the cloud posture exists to protect. Capture the inventory and classification, the at-rest encryption posture per service, the in-transit encryption posture, the key management posture, the object storage exposure check, the database posture, and the data residency posture. The block reads against ISO 27001 Annex A 5.10 through A 5.14 and A 8.24, SOC 2 CC6.1 and CC6.7, PCI DSS Requirements 3 and 4, NIST SP 800-53 SC-12 and SC-13 and SC-28, GDPR Articles 5 and 32, CSA CCM DSI domain, and the named cloud provider key-management baselines.
Data inventory and classification posture:
[ ] Named data classes documented (public, internal, confidential, restricted, regulated-cardholder, regulated-health, regulated-personal)
[ ] Each in-scope cloud storage service mapped to the data class it carries (S3 buckets, Azure Blob containers, GCS buckets, RDS instances, DynamoDB tables, Cosmos DB databases, Cloud SQL instances, BigQuery datasets, file shares)
[ ] Confidential and regulated data segmented into distinct accounts, subscriptions, or projects where feasible
Encryption at rest posture:
[ ] Default encryption enabled across every relevant service (S3 default encryption, Azure Storage default encryption, GCS default encryption, RDS encryption, EBS default encryption, EFS encryption, FSx encryption, Azure Disk encryption, GCP persistent disk encryption)
[ ] Customer-managed key (CMK) decision documented per data class (managed-key acceptable for non-confidential; CMK required for regulated and confidential)
[ ] CMK rotation cadence configured per cloud (AWS KMS automatic key rotation, Azure Key Vault key rotation policy, Cloud KMS rotation schedule)
[ ] Key separation enforced across environments (separate keys per production/non-production/regulated)
[ ] Dual control on key destruction (key deletion requires named approver and waiting period)
Encryption in transit posture:
[ ] TLS minimum version enforced per service (TLS 1.2 minimum; TLS 1.3 preferred)
[ ] Public-facing load balancer and CDN TLS configuration audited (ciphers, certificate chain, HSTS where applicable)
[ ] Internal service-to-service encryption posture documented (VPC endpoints with policy, AWS PrivateLink, Azure Private Endpoint, GCP Private Service Connect)
[ ] Mutual TLS posture documented where required (cell-to-cell, service-to-service in zero-trust posture)
Key management posture:
[ ] KMS or HSM service in use per cloud documented
[ ] Key inventory complete (active keys, deprecated keys, scheduled-for-deletion keys, count per cloud)
[ ] Key import audit complete (externally-managed keys imported into the cloud KMS are inventoried and rotated)
[ ] Key access policy audit complete (named principals per key; cross-account key sharing audited)
[ ] Key access logged into the centralised log store
Object storage exposure posture:
[ ] Public-bucket inventory complete (S3 buckets with public ACL, public bucket policy, or static website hosting; Azure storage with public-blob access; GCS buckets with allUsers or allAuthenticatedUsers)
[ ] Block-public-access enforced at the account or subscription or project level
[ ] Bucket access logging enabled across buckets carrying confidential or regulated data
[ ] Presigned URL audit complete (named workflows that issue presigned URLs and their expiry)
[ ] Server-side request forgery (SSRF) protection enabled on metadata services (IMDSv2 on AWS, IMDS protection on Azure, GCP metadata server scope)
Database posture:
[ ] Managed database encryption at rest enabled (RDS, Aurora, DynamoDB, DocumentDB, Redshift; Azure SQL, Cosmos DB, MySQL flexible server; Cloud SQL, Cloud Spanner, BigQuery)
[ ] Backup encryption enabled and tested
[ ] Connection encryption enforced (SSL/TLS required at the connection string level)
[ ] Snapshot exposure check complete (snapshots are not publicly shared, are not cross-account shared without rationale)
[ ] Database public endpoint audit complete (databases are not exposed to the public internet without rationale)
Data residency posture:
[ ] In-region storage commitments documented per data class
[ ] Replication boundary configured against the residency commitment
[ ] Regulatory data residency check complete (GDPR for personal data of EU residents; sector and national obligations where applicable)
4. Network and perimeter posture
Network posture in the cloud is a moving boundary that shifts with every deployment. Capture the network architecture inventory, the perimeter posture, the segmentation posture, the inbound and outbound traffic posture, and the DDoS and WAF posture. The block reads against ISO 27001 Annex A 8.20 through A 8.23, SOC 2 CC6.6, PCI DSS Requirement 1, NIST SP 800-53 SC-7 family, CIS Benchmarks network sections, AWS Well-Architected Security Pillar SEC05, Azure Security Benchmark NS, and GCP Security Foundations Blueprint network section.
Network architecture inventory:
[ ] VPC, vNet, and VPC inventory complete per cloud (CIDR allocation, peering map, transit gateway map, NAT and internet gateway inventory)
[ ] Account-to-account, subscription-to-subscription, project-to-project peering map complete with named purpose
[ ] Hybrid connectivity inventory complete (Direct Connect, ExpressRoute, Cloud Interconnect, VPN connections, SD-WAN integrations)
[ ] DNS posture documented (Route 53, Azure DNS, Cloud DNS; private hosted zones; conditional forwarding posture)
Perimeter posture:
[ ] Public IP inventory complete (named public IPs, named exposure, named owner; orphaned public IPs flagged)
[ ] Public-facing load balancer inventory complete with TLS configuration and WAF coverage flag
[ ] Public-facing storage account, container registry, and managed database inventory complete with rationale
[ ] Public-facing serverless endpoint inventory complete (API Gateway, Azure Functions HTTP triggers, Cloud Functions HTTP triggers, Cloud Run public services)
[ ] Public-facing IDE, RDP, and SSH inventory complete (target zero; remaining exceptions carry a named SLA tier and a session-broker mitigation)
Segmentation posture:
[ ] Workload-tier separation documented (web tier, application tier, data tier; named security groups, NSGs, firewall rules per tier)
[ ] Zero-trust posture documented where claimed (named identity provider, named service-to-service authentication, named policy engine)
[ ] Cross-account, cross-subscription, cross-project network segmentation reviewed
[ ] PCI cardholder data environment (CDE) segmentation evidenced (CIS PCI mapping, network diagram, named scoping evidence) where in scope
Inbound traffic posture:
[ ] Security group, NSG, and firewall rule inventory complete (count, last review date, named owner)
[ ] Inbound rule audit complete (open-to-the-world rules carry a named justification; wide-open ports flagged)
[ ] Inbound rule reviewer cadence documented (quarterly default)
Outbound traffic posture:
[ ] Egress filtering posture documented (proxy, gateway, named allowlist domains)
[ ] Outbound rule audit complete (named outbound destinations are documented; unintended exfiltration paths flagged)
[ ] DNS exfiltration protection posture documented (named DNS firewall or DNS security service)
DDoS and WAF posture:
[ ] DDoS protection posture documented per cloud (Shield Standard or Advanced on AWS, Azure DDoS Protection Standard, Cloud Armor on GCP)
[ ] Web application firewall posture documented per public-facing application (AWS WAF, Azure WAF on Front Door or Application Gateway, Cloud Armor, third-party WAF) with named rule set and last review date
[ ] WAF logs streaming into the centralised log store
[ ] Bot management posture documented for high-value public-facing applications
5. Workload and runtime posture
Workloads in the cloud span virtual machines, container images, Kubernetes clusters, serverless functions, managed services, and the platform layer underneath. Each workload class has its own posture and its own evidence chain. The block reads against ISO 27001 Annex A 8.8 management of technical vulnerabilities, A 8.9 configuration management, A 8.28 secure coding; SOC 2 CC7 and CC8; PCI DSS Requirement 6 and 11; NIST SP 800-53 CM and SI families; CIS Benchmarks per workload class; CIS Kubernetes Benchmark for clusters; AWS Well-Architected Security Pillar SEC06; Azure Security Benchmark CM; GCP Security Foundations Blueprint compute section.
Virtual machine posture:
[ ] VM image source documented (hardened golden image; vendor image with hardening overlay; vendor image without hardening flagged)
[ ] Patch state inventory complete (named patch baseline, named cadence, exception list)
[ ] Hardening baseline named per OS family (CIS Linux, CIS Windows, vendor-provided hardening profile)
[ ] Host-based agent presence documented (EDR, anti-malware, file integrity monitoring, vulnerability scanning agent, log shipper, configuration management agent)
[ ] Exposed metadata service version audited (IMDSv2 enforced on AWS where supported; IMDS protection on Azure; restrictive metadata server scope on GCP)
Container image posture:
[ ] Image source registry inventory complete (named internal registry, named base image source, named third-party registry use)
[ ] Base image inventory complete with named owner per image (distroless, alpine, minimal OS, vendor-provided runtime image)
[ ] Image vulnerability scan posture documented (named scanner, named cadence, named severity-band fail threshold; pair with the container image vulnerability remediation workflow)
[ ] Image signing and provenance posture documented (Sigstore cosign, Notary, vendor-provided image signing)
[ ] Container runtime configuration audited (no privileged containers where unnecessary, no host network or host PID, capability drop, read-only filesystem where feasible, non-root execution)
Kubernetes posture (where in scope):
[ ] Control plane configuration audited against CIS Kubernetes Benchmark (API server, etcd, controller manager, scheduler, kubelet)
[ ] RBAC review complete (named subject-to-role bindings, cluster-admin grant audit, service account audit)
[ ] Network policy posture documented (default deny, named ingress and egress policies per namespace)
[ ] Admission controller posture documented (named policy engine: Kyverno, OPA Gatekeeper, native Pod Security Standards, Connaisseur for image signing)
[ ] Pod Security Standard posture per namespace (privileged/baseline/restricted assignment documented)
[ ] Secret management posture documented (sealed secrets, external secret operator with cloud KMS, named secret rotation cadence)
[ ] Cluster posture review pair: see the Kubernetes security finding remediation workflow for the per-cluster finding lifecycle
Serverless posture:
[ ] Function inventory complete (named function, named purpose, named owner, named runtime version)
[ ] Function execution role audited per function (least privilege named, wildcard action audit)
[ ] Event source audit complete (named event source per function; public event source flagged)
[ ] Environment variable secret audit complete (named secret per function; plain-text secret flagged)
[ ] Runtime version posture documented (named end-of-life date per runtime version; deprecated runtime flagged)
[ ] Function timeout and concurrency posture documented (named denial-of-wallet protection)
Managed service posture:
[ ] Managed database engine version inventory complete (named end-of-life date; deprecated engine version flagged)
[ ] Search and queue service posture documented (OpenSearch, Elasticsearch Service, SQS, Service Bus, Pub/Sub, Cloud Tasks)
[ ] AI and ML service posture documented (Bedrock, SageMaker, Azure OpenAI, Azure Machine Learning, Vertex AI; data-egress posture, model-access posture, training-data posture)
[ ] Container registry posture documented (named scanner integration, vulnerability gate, immutability flag, retention policy)
Platform posture:
[ ] Operating system patch state on platform-as-a-service offerings audited (managed runtimes carry vendor patch obligations; named upgrade cadence documented where customer-owned)
[ ] Dependency stack posture documented (named software bill of materials for first-party code; pair with the SBOM policy template)
[ ] Build pipeline access review complete (named CI/CD service accounts, named protected branches, named approval requirement on protected branches, named code-signing posture)
6. Logging, monitoring, and detection posture
Telemetry is what makes the cloud estate visible to incident response, threat hunting, forensic reconstruction, and detection engineering. Capture the control-plane logging posture, data-plane logging posture, cloud-native security service posture, centralisation posture, detection content posture, alert routing posture, and forensic readiness posture. The block reads against ISO 27001 Annex A 8.15 and A 8.16, SOC 2 CC7.2 and CC7.3, PCI DSS Requirement 10, NIST SP 800-53 AU and SI families, NIST CSF 2.0 DE.CM and DE.AE, NIS2 Article 21(2)(b), DORA Article 17 ICT incident management; pair with the detection engineering cycle template.
Control-plane logging posture:
[ ] CloudTrail multi-region trail enabled on every AWS account with management events; data event logging enabled on storage and on identity-sensitive services as required by data classification
[ ] Azure Activity Logs streaming on every subscription
[ ] GCP Cloud Audit Logs (Admin Activity, Data Access where applicable, System Event, Policy Denied) streaming on every project
[ ] Log scope coverage check complete (no in-scope account or subscription or project missing a log stream)
Data-plane logging posture:
[ ] S3 server access logs enabled on confidential and regulated buckets
[ ] Azure Storage diagnostic logs enabled on confidential and regulated storage accounts
[ ] GCS data access logs enabled where required by data classification
[ ] Database audit logs enabled on managed databases carrying regulated data
[ ] API Gateway, load balancer, CDN, and ingress access logs streaming on public-facing application paths
[ ] Application-tier logging posture documented (named correlation identifier, named structured-log standard, named log level discipline)
Cloud-native security service posture:
[ ] AWS GuardDuty, Security Hub, and Inspector posture documented per account (enabled, findings ingested, named owner)
[ ] Azure Defender for Cloud, Defender for Identity, and Sentinel posture documented per subscription
[ ] GCP Security Command Center and Chronicle posture documented per project
[ ] Provider-side findings flow into the same workspace as scanner-side findings (named import path)
Centralisation posture:
[ ] Centralised log store named (named service, named region, named retention, named encryption)
[ ] Log integrity verification enabled (CloudTrail log file integrity, immutable storage on centralised store with object lock or equivalent)
[ ] Centralised store access policy reviewed (write-only on producer side, read-restricted on consumer side, no public access)
[ ] Centralised store retention configured against the longest applicable framework expectation
Detection content posture:
[ ] CSPM-side detection rules inventoried (count, last review date, named owner)
[ ] Identity threat detection rules inventoried (impossible travel, anomalous role assumption, privilege escalation pattern, MFA fatigue pattern)
[ ] Data exfiltration detection rules inventoried (large egress, anomalous S3 GetObject volume, unusual database export, anomalous DNS exfiltration pattern)
[ ] Runtime detection on workloads where deployed (named EDR or runtime scanner)
[ ] Detection content lifecycle pair: see the detection engineering cycle template for the rule write-tune-retire discipline
Alert routing posture:
[ ] Named runbook per alert class
[ ] Named on-call rotation per alert class
[ ] Mean-time-to-acknowledge target per severity band
[ ] Named integration into the workspace finding system (cloud security findings land on the same engagement record as scanner findings via bulk finding import or named ingestion path)
Forensic readiness posture:
[ ] Snapshot capability documented per workload class (named snapshot service, named retention)
[ ] Isolation runbook documented (named procedure to isolate a compromised account, subscription, project, instance, container, function)
[ ] Incident response runbook referenced (pair with the incident response runbook template)
7. Vulnerability and patch posture across cloud workloads
Cloud workloads carry CVEs, EOL components, missing patches, and outdated dependencies just as on-premises workloads do, but the cadence and the ownership pattern differ. Capture the vulnerability scan posture, the patch posture, the EOL inventory, the third-party dependency posture, and the remediation SLA posture for each workload class. The block reads against ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS Requirement 6.3 and 11.3, NIST SP 800-53 RA-5 and SI-2; pair with the vulnerability management policy template and the vulnerability remediation runbook template.
Vulnerability scan coverage posture:
[ ] External scan coverage of public-facing cloud workloads (named cadence, last scan date, scan result reference)
[ ] Authenticated scan coverage of cloud-hosted web applications (named cadence, last scan date, scan result reference)
[ ] Code scan coverage of cloud-deployed first-party code (SAST and SCA via named scanners; pair with code scanning)
[ ] CSPM coverage of cloud control plane (named tool, named cadence)
[ ] Container image scan coverage on every image pushed to the registry (named scanner, named cadence, named severity-band fail threshold)
[ ] Cloud workload scan coverage (named runtime scanner, named cadence)
[ ] Coverage gap inventory complete (named workloads not yet under any scanner; named remediation path)
Patch posture:
[ ] Named patch cadence per OS family (critical: 14 days; high: 30 days; medium: 60 days; low: 90 days; default tier rationale documented)
[ ] Named patch cadence per managed-service engine (database engine, runtime version, container base image)
[ ] Patch deviation list (workloads whose patch cadence is paused; named justification, named expiry, named approver)
End-of-life inventory:
[ ] EOL operating system inventory (named instances, named EOL date, named migration plan)
[ ] EOL database engine inventory (named instances, named EOL date, named migration plan)
[ ] EOL runtime inventory (named functions, named runtime version, named EOL date)
Third-party dependency posture:
[ ] Software bill of materials posture documented (named SBOM emission for first-party code; pair with the SBOM policy template)
[ ] Dependency vulnerability scan posture documented (named scanner, named cadence, named severity-band fail threshold)
[ ] Reachability analysis posture documented for high-volume dependency findings (named tool or named manual process)
Remediation SLA posture:
[ ] Named SLA tier per severity band documented (pair with the vulnerability SLA policy template)
[ ] SLA breach escalation path named per severity band (pair with the vulnerability SLA breach escalation use case)
[ ] Open finding inventory complete by severity band and by workload class with named owner per cluster of findings
8. Configuration and posture management baselines
A cloud account drifts every day. Capture the configuration baseline posture against named provider and CIS baselines, the drift detection posture, the infrastructure-as-code posture, the change management posture, and the posture-management tool posture. The block reads against ISO 27001 Annex A 8.9, SOC 2 CC7.1 and CC8.1, PCI DSS Requirements 1.2 and 2.2, NIST SP 800-53 CM family, CIS Benchmarks per provider, AWS Well-Architected SEC, Azure Security Benchmark CM and AC, GCP Security Foundations Blueprint configuration section.
Configuration baseline posture:
[ ] Named provider baseline in use per cloud (AWS Foundational Security Best Practices, Azure Security Benchmark, GCP Security Foundations Blueprint)
[ ] Named CIS Benchmark version in use per cloud (CIS AWS Benchmark, CIS Azure Benchmark, CIS GCP Benchmark)
[ ] Provider-side findings flow into the workspace finding system (named import path)
Drift detection posture:
[ ] Named drift detection tool in use (CSPM tool, named cloud-native posture service, CNAPP)
[ ] Named drift remediation path (manual remediation, IaC reconciliation, auto-remediation with named guardrails)
[ ] Drift event audit complete (drift events are logged into the centralised store with named investigator response)
Infrastructure-as-code posture:
[ ] Named IaC tool in use per cloud (Terraform, Pulumi, AWS CloudFormation, Azure Bicep, GCP Deployment Manager, AWS CDK, Azure CDK)
[ ] IaC repository inventory complete (named repository per cloud, named code owner, named branch protection)
[ ] IaC scanning posture documented (named scanner: Checkov, tfsec, KICS, Semgrep, Snyk IaC; named severity-band fail threshold)
[ ] IaC drift-from-state posture documented (named reconciliation path)
[ ] IaC merge-to-deploy chain audited (named approval gate, named code signing, named deploy account)
Change management posture:
[ ] Named change classes documented (standard, normal, emergency)
[ ] Named approval requirement per change class
[ ] Named change record path (named ticketing system, named change advisory board for high-risk classes)
[ ] Named post-implementation review for emergency changes
Posture management tool posture:
[ ] Named CSPM, CNAPP, or cloud-native security service in use per cloud
[ ] Named cadence of CSPM finding review
[ ] CSPM finding lifecycle pair: see the CSPM finding remediation workflow for the per-finding remediation discipline
9. Third-party and supplier-managed service posture
A cloud estate depends on supplier-managed services. Capture the supplier inventory, the supplier security review posture, the data-sharing posture, the cross-cloud and cross-tenant posture, and the supplier incident notification posture. The block reads against ISO 27001 Annex A 5.19 through A 5.23 supplier relationships, ISO/IEC 27036 supplier security, SOC 2 CC9.2, PCI DSS Requirement 12.8, NIST SP 800-53 SR family supplier risk, NIST SP 800-161 supply chain, DORA Articles 28 through 30 third-party ICT services for in-scope financial entities, NIS2 Article 21(2)(d) supply chain security.
Supplier inventory:
[ ] Named cloud platform providers documented (AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud, IBM Cloud, Tencent Cloud, OVH Cloud, Hetzner, DigitalOcean, Linode)
[ ] Named third-party SaaS suppliers consumed from cloud workloads (named purpose, named data class, named integration path)
[ ] Named third-party AI and ML providers consumed (named purpose, named data class, named data egress posture)
[ ] Named third-party identity, security, observability, and CI/CD providers integrated to cloud workloads
Supplier security review posture:
[ ] Named cadence of supplier security review (annual default; risk-tiered for high-criticality suppliers)
[ ] Named evidence collected per supplier (SOC 2 Type II report, ISO 27001 certificate, ISO 27017 cloud-specific evidence, ISO 27018 personal-data cloud evidence, named pentest summary, named regulator certification where applicable)
[ ] Supplier risk register entry complete per supplier (pair with the vendor security risk assessment template)
[ ] Departed supplier audit (suppliers no longer in use have data deletion evidence and credential revocation evidence)
Data-sharing posture:
[ ] Named data classes shared with each supplier
[ ] Named legal basis per shared data class (contract, regulatory, consent)
[ ] Named data processing agreement posture for personal data sharing (GDPR Article 28 controller-to-processor terms)
[ ] Named cross-border data flow posture for personal data sharing (Standard Contractual Clauses, adequacy decision, named data localisation commitment)
Cross-cloud and cross-tenant posture:
[ ] Cross-cloud trust posture documented (named identity federation, named key-sharing posture, named network posture)
[ ] Cross-tenant trust posture documented for B2B integrations (named partner tenant inventory, named scope per partner, named expiry per partner)
Supplier incident notification posture:
[ ] Named supplier notification window per supplier (24h, 48h, 72h, regulator-driven)
[ ] Named supplier incident contact per supplier
[ ] Named supplier breach evidence pack request path
10. Resilience, backup, and disaster recovery posture
Cloud workloads can fail because of provider outage, configuration error, ransomware, or accidental deletion. Capture the backup posture, the immutability posture, the disaster recovery posture, the RTO/RPO/MTPD alignment posture, and the exercise posture. The block reads against ISO 27001 Annex A 5.29 ICT disruption, A 5.30 ICT readiness, A 8.13 backup, A 8.14 redundancy; ISO/IEC 27031 ICT readiness for business continuity; ISO/IEC 22301 BCMS; SOC 2 A1 availability where in scope; PCI DSS Requirement 9.5; NIST SP 800-53 CP family; NIST CSF 2.0 RC.RP recovery planning; DORA Article 11 ICT business continuity and Article 12 backup; NIS2 Article 21(2)(c) business continuity; pair with the business continuity and disaster recovery plan template and the ISO/IEC 27031 framework page.
Backup posture:
[ ] Named backup policy per data class
[ ] Named backup retention per data class
[ ] Backup inventory complete per workload class (managed databases, object storage, VMs, container persistent volumes, file shares)
[ ] Backup encryption enabled and tested
[ ] Backup access policy audited (named principal can write, named principal can read, named principal can restore)
Immutability posture:
[ ] Named object lock or immutability mode on backup destinations (S3 Object Lock compliance mode, Azure Blob immutability policy, GCS bucket lock)
[ ] Named retention period on immutability policy aligned to the named backup retention
[ ] Named immutability policy review cadence
Disaster recovery posture:
[ ] Named DR strategy per workload class (backup-and-restore, pilot-light, warm-standby, multi-site active-active)
[ ] Named secondary region per cloud
[ ] Named cross-cloud DR posture where applicable
[ ] Named recovery runbook per workload class
[ ] Named DR cutover authority per workload class
RTO/RPO/MTPD alignment posture:
[ ] Named RTO per workload class
[ ] Named RPO per workload class
[ ] Named MTPD per workload class
[ ] Named alignment to BCMS RTO/RPO/MTPD where in scope
Exercise posture:
[ ] Named exercise cadence per DR strategy tier
[ ] Last exercise date and outcome documented per workload class
[ ] Exercise findings tracked as findings on the workspace finding system with named owner and named close target
11. Findings, exceptions, and remediation routing
Every assessment produces findings. Capture each finding with a named owner, a calibrated severity, a target close date, a remediation type, a retest cadence, and an evidence-of-closure expectation. Capture each accepted-risk decision through an exception block with named approver, named compensating control, named expiry, and named renewal cadence. The block reads against ISO 27001 Annex A 5.4 risk treatment, A 5.36 compliance, A 8.8 vulnerability management; SOC 2 CC3.2; PCI DSS Requirement 12.3 risk-based approach and Requirement 12.10.1 risk acceptance evidence; NIST SP 800-53 RA-7 risk response; pair with the security exception register template, the risk acceptance form template, and the vulnerability prioritisation matrix template.
Per-finding capture:
- Finding identifier (workspace finding ID): {{FINDING_ID}}
- Linked section reference (sections 2 through 10): {{LINKED_SECTION}}
- Linked control reference (named CSA CCM, ISO 27001 Annex A, SOC 2, PCI DSS, NIST control): {{LINKED_CONTROL}}
- Severity calibration:
- Technical finding (CVSS 3.1 vector, score, severity band): {{CVSS_VECTOR}} / {{CVSS_SCORE}} / {{CVSS_SEVERITY}}
- Control gap (severity rubric: critical, high, medium, low, informational; rationale): {{CONTROL_GAP_SEVERITY}}
- Named owner (the role and the person at time of capture): {{FINDING_OWNER_ROLE}} / {{FINDING_OWNER_NAME}}
- Target close date (against the SLA tier the owning team operates against): {{TARGET_CLOSE_DATE}}
- Remediation type (configuration change, code change, identity remediation, architecture remediation, compensating control, accept-residual-risk): {{REMEDIATION_TYPE}}
- Retest cadence (one-time retest, scheduled retest, continuous monitoring): {{RETEST_CADENCE}}
- Evidence-of-closure expectation (configuration export, scanner output, attestation, code commit reference, pull request reference): {{EVIDENCE_OF_CLOSURE}}
Per-exception capture (for findings the assessment proposes to accept as residual risk):
- Exception identifier (workspace exception register entry): {{EXCEPTION_ID}}
- Linked finding identifier: {{LINKED_FINDING_ID}}
- Residual risk rationale (one paragraph): {{RESIDUAL_RISK_RATIONALE}}
- Named approver (role plus person; appropriate to severity band): {{APPROVER_ROLE}} / {{APPROVER_NAME}}
- Named compensating control where any (named control plus named owner): {{COMPENSATING_CONTROL}}
- Named expiry date: {{EXPIRY_DATE}}
- Named renewal cadence: {{RENEWAL_CADENCE}}
- Named residual risk owner (the named role responsible for carrying the residual risk position): {{RESIDUAL_RISK_OWNER}}
Remediation roll-up:
[ ] Open finding count by severity band and by section documented
[ ] Closed finding count for the assessment window documented (with evidence-of-closure reference)
[ ] Accepted-risk exception count by severity band and by section documented
[ ] Findings without a named owner flagged for immediate routing
[ ] Findings without a target close date flagged for immediate routing
12. Framework evidence pack and sign-off
The assessment artefact has to satisfy the framework expectations it claims to evidence. Capture the per-framework evidence map, the audit-readiness check, the customer-facing summary anchor, the publication path, and the four-signature sign-off block. The block reads against the named framework set declared in Section 1 and produces the read the auditor, the regulator, the customer security questionnaire reviewer, and the audit committee chair all need.
Per-framework evidence map:
[ ] CSA CCM v4 map complete (named domain IDs the assessment evidences with named section references)
[ ] ISO/IEC 27017 map complete (CLD controls mapped to assessment sections)
[ ] ISO/IEC 27018 map complete where personal data is processed in the cloud
[ ] ISO/IEC 27001 Annex A map complete (A 5.23, A 5.30, A 8.8, A 8.16, A 8.20, A 8.24 plus the wider control set the assessment touches)
[ ] SOC 2 Trust Services Criteria map complete (CC6, CC7, CC8, A1 where in scope)
[ ] PCI DSS map complete where cardholder data is in scope (Req 1, 2, 3, 4, 6, 8, 10, 11, 12)
[ ] NIST SP 800-53 Rev 5 map complete (AC, AU, CA, CM, CP, IA, RA, SC, SI families)
[ ] NIST CSF 2.0 map complete (Identify, Protect, Detect, Respond, Recover, Govern functions)
[ ] CIS Benchmarks map complete (AWS, Azure, GCP control IDs)
[ ] Provider-specific map complete (AWS Well-Architected Security Pillar, Azure Security Benchmark, GCP Security Foundations Blueprint)
[ ] Regulatory map complete (NIS2 Article 21, DORA Article 6, FedRAMP baseline, sector overlays as applicable)
[ ] Internal cloud security policy map complete
Audit-readiness check:
[ ] Every framework control mapped to evidence in at least one section
[ ] Every framework control gap mapped to a named finding in Section 11
[ ] Every accepted-risk decision in Section 11 mapped to a named exception register entry
[ ] Every assessment section has a named author and a named reviewer signature
[ ] Every finding has a named owner and a named target close date
Customer-facing summary anchor:
[ ] One-page customer summary drafted (named control areas reviewed, named provider posture, named residual risk position; pair with AI reports for the draft)
[ ] Customer security questionnaire response pack drafted from the assessment evidence
Publication path:
[ ] Assessment artefact stored in the workspace document store with named retention class
[ ] Assessment artefact named version, named effective date, named next-review date
[ ] Assessment artefact distribution list documented (named internal recipients; named auditor on request; named customer on request through the customer security evidence room use case)
Four-signature sign-off block:
- Assessment owner signature and date: {{ASSESSMENT_OWNER_SIGNATURE}} / {{ASSESSMENT_OWNER_SIGNATURE_DATE}}
- GRC reviewer signature and date: {{GRC_REVIEWER_SIGNATURE}} / {{GRC_REVIEWER_SIGNATURE_DATE}}
- Section author roll-up sign-off (each section author has signed their section): {{SECTION_AUTHOR_ROLL_UP_CONFIRMED}}
- Executive sign-off signature and date (security operations leader, CISO, security director, or risk-committee chair): {{EXECUTIVE_SIGN_OFF_SIGNATURE}} / {{EXECUTIVE_SIGN_OFF_SIGNATURE_DATE}}
Eight failure modes the checklist has to design against
The checklist fails the audit read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before customising the checklist so the customisation does not weaken the discipline that makes the assessment defensible.
Checklist drifts into screenshot collection
The team treats the checklist as a slot for cloud console screenshots rather than as a controlled review. By assessment three the artefact is a folder of dashboard captures with no per-control narrative, no named author, no severity calibration, and no remediation routing. The audit reads the absence of a structured per-section answer as the absence of the assessment. Run each section against the controlled body block, capture the named control read in writing, and treat screenshots as supporting evidence rather than as the assessment itself.
Dominant cloud passes implicitly waves the others through
The team runs the checklist against the dominant cloud (often AWS) and then implicitly approves Azure and GCP because the dominant cloud passed. Each minor cloud carries its own configuration, identity surface, default behaviour, and security service stack. The audit reads the absence of a per-cloud answer as a coverage gap. Run every section per cloud where the implementation differs, even if the answer is short, and record the per-cloud control read explicitly.
Findings exist but routing does not
The assessment surfaces real findings but nothing happens to them after the artefact is signed. The findings stay on the assessment document while the operational queue continues without them, and by the next assessment the same findings reappear with a new identifier. Route every finding from Section 11 onto the workspace finding system with a named owner, a target close date, an SLA tier, a retest cadence, and an evidence-of-closure expectation, and treat the assessment as the seed of remediation work rather than as a standalone document.
Accepted risk has no expiry and no renewal cadence
Exceptions accumulate without expiry, without compensating control, and without a renewal cadence. By assessment three the exception list is longer than the open finding list and the residual risk position is opaque. Record every exception with a named approver, a named compensating control, a named expiry, a named renewal cadence, and a named residual risk owner on the exception register, and treat the exception list as a controlled artefact in its own right rather than as a parking lot for findings the team did not want to fix.
Framework evidence map drifts away from assessment content
The framework evidence map at Section 12 is written once at the start of the programme and never updated as the assessment content moves. Auditors test the map against the actual content and find that the named control references no longer point to a real section answer. Rebuild the framework evidence map at the end of every assessment from the actual section content, treat the map as an output of the assessment rather than as a static appendix, and record the named section-to-control reference in the map itself.
CSPM scanner output and assessment artefact diverge
The continuous CSPM stream produces a real-time finding feed and the assessment artefact produces a periodic narrative. The two queues never reconcile, the same finding appears in both with different severity calibrations, and the named owner on the CSPM-side finding is different from the named owner on the assessment-side finding. Land both into the same workspace finding system through bulk finding import where the CSPM tool emits CSV exports, calibrate severity once on the workspace finding identity, and treat the assessment as the periodic narrative that reads against the continuous stream rather than as a parallel discipline.
Multi-cloud trust paths invisible to the assessment
The assessment reads each cloud in isolation and never names the cross-cloud trust paths (cross-account IAM federation, cross-cloud network peering, cross-cloud workload identity federation, shared secrets between clouds, shared CI/CD pipelines that deploy across clouds). A compromise on the weakest cloud propagates to the strongest cloud through a trust path that the assessment never captured. Add a cross-cloud trust map to Section 4 and a cross-cloud federation audit to Section 2 even when the underlying clouds are run by different teams.
Sign-off shifts from named role to anonymous spreadsheet output
Over time, the four-signature block at Section 12 erodes into a single signature or no signature, and the assessment becomes an anonymous spreadsheet output that any reviewer can dispute. Enforce the four-signature block on every assessment publication (assessment owner, GRC reviewer, section author roll-up, executive sign-off) so the artefact reads as a controlled deliverable produced by named individuals on a named date against a named scope, rather than as an internal working document that nobody owns.
Ten questions a quarterly assessment review has to answer
Per-section review keeps each control read current. Assessment-wide review answers the cumulative question: is the cloud estate durably audit-ready, and is the programme on top of the findings, the exceptions, and the framework evidence map. Run these ten questions at every assessment close and capture the answers in the assessment-level summary section.
1.How many sections in the most recent assessment carry a named author, a named reviewer, and a sign-off date, broken out by cloud provider.
2.How many open findings from Section 11 carry a named owner, a target close date, a severity calibration, and a retest cadence at the close of the assessment window.
3.How many accepted-risk exceptions from Section 11 carry a named approver, a named compensating control, a named expiry, and a named residual risk owner.
4.Which control families in the framework evidence map at Section 12 carry the largest count of gaps and how does the trend compare to the prior assessment.
5.How many findings from the assessment have been imported onto the workspace finding system within fourteen days of assessment close, with a named SLA tier.
6.Which event-driven triggers fired during the assessment window and which produced a scoped re-assessment artefact.
7.How many cross-cloud trust paths were named in the assessment and how does that count compare to the prior assessment.
8.How many findings from the continuous CSPM stream were reconciled against findings on the assessment artefact and how many remained orphaned at assessment close.
9.Which sections required the largest narrative correction between the draft and the signed assessment and what caused the correction.
10.How many residual risk positions from prior assessments closed during this assessment window and how many migrated forward as renewed exceptions.
How the checklist pairs with SecPortal
The template above is copy-ready as a standalone artefact. If the team already runs finding tracking, scan execution, document storage, and framework evidence packaging on a workspace, the checklist becomes the byproduct of the assessment work rather than a separate document. SecPortal pairs each assessment to a versioned record through engagement management so the in-scope cloud account list, the named author and reviewer per section, the attached evidence, the four-signature block, and the framework evidence map all live on one record with a single revision history. The findings management feature captures every finding from Section 11 under the unified schema with CVSS 3.1 calibration, severity, target close date, named owner, named retest pointer, and named evidence-of-closure expectation, so the assessment seeds the operational queue rather than producing an isolated document.
The bulk finding import path ingests CSV exports from CSPM, CNAPP, cloud-native security service, container image scanner, IaC scanner, and external scan output, so the cloud-side findings land alongside the wider security backlog under the same workspace finding identity. The finding overrides feature carries the eight-field exception decision chain for residual risk positions captured in Section 11 (named approver, named compensating control, named expiry, named renewal cadence, named residual risk owner, named scope, named justification, named review history) so the accepted-risk register stays on the live record rather than on a side spreadsheet. The activity log captures status transitions on every entity (finding, engagement, scan, document, comment) by user and timestamp with CSV export, so the assessment audit chain is recorded automatically as a side effect of the work and the named-author signature trail at the section level is reproducible.
The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks with CSV export, so the framework evidence map at Section 12 can be sliced by framework when an auditor asks for the evidence pack against a specific control set. The continuous monitoring feature schedules domain and authenticated scans on a named cadence so the public-facing posture from Section 4 and the workload-tier posture from Section 5 stay current between assessment cycles. The retesting workflows feature carries the per-finding retest cycle that Section 11 commits to, so the evidence-of-closure expectation at finding capture becomes an executable workflow rather than a written promise.
The team management feature carries the role-based access control that decides which roles can author each section, which roles can countersign, which roles can publish, and which roles can sign off at executive level. The multi-factor authentication control gates workspace access at AAL2 so the audit reads the access record as a documented control rather than as a hope. The AI report generation workflow can draft the customer-facing summary anchor at Section 12, the audit committee narrative, and the executive briefing pack from the same engagement data, so the publication path produces multiple consumer-shaped reads of the same underlying assessment without re-keying.
Honest scope: SecPortal is not a CSPM, not a CNAPP, not a cloud workload protection platform, and not a Kubernetes security posture management product. It does not ship native AWS, Azure, or Google Cloud API integrations against the cloud control plane, does not run continuous configuration scanning against named cloud accounts, does not run runtime detection agents on cloud workloads, does not ship native Jira, ServiceNow, Slack, PagerDuty, SIEM, or SOAR connectors for finding push, and does not act as the identity provider, the policy engine, or the cloud-native posture service. It serves as the consolidated operating record an internal security, cloud security, AppSec, vulnerability management, or GRC team uses to track cloud findings imported from a dedicated CSPM platform, a CNAPP, a cloud-native security service, a manual cloud review, or a third-party cloud penetration test.
Who reads the assessment artefact
Cloud security and AppSec teams
Cloud security engineers, AppSec engineers, product security teams, and platform engineering teams read the checklist as the per-cycle deliverable that captures the named control read against each named cloud account. Pair the checklist with the cloud security teams persona page and the AppSec teams persona page for the broader operating context.
CISOs, security directors, and security architects read the assessment as the cross-cloud posture deliverable that informs the strategic posture decisions and the quarterly governance review. Pair the checklist with the CISOs persona page and the security leadership reporting use case.