CYBER RISK & RESILIENCE
Your Cloud Team Needs a Clear View of Risk, Ownership and Evidence.
A customer asks how cloud access is controlled. Logging is enabled but responsibility for reviewing it is unclear. Backups exist without usable recovery evidence. We help assess scoped AWS and Azure environments and connect configuration observations to security governance and compliance evidence.
Free 30-minute cloud security strategy call. No obligation.
01
EXPERTISE. LED BY TEMI.
Every engagement is led by Temi. Over two decades of security, audit and governance experience, applied to your business.
02
Agree the engagement boundary
The broad offer focuses on scoped AWS and Azure services. Other platforms and Microsoft 365 workloads need an explicit scope decision. Production configuration changes, architecture development, infrastructure-as-code, continuous monitoring and active incident response require separately defined delivery responsibilities and authorization.
03
When a scoped cloud review is useful
A migration, a growing number of accounts, a new buyer requirement or a change in service ownership can make existing evidence difficult to interpret. Start with the business decision: whether a planned environment is ready for review, which inherited risks need attention, or what records a customer or assessor needs.
For environments spanning several providers or on-premises systems, the scope identifies the dependencies and handoffs that affect the selected AWS and Azure services. Other platforms and Microsoft 365 workloads require an explicit scope decision; their presence does not make them part of this engagement.
04
Cloud assurance starts with responsibility
The cloud provider secures parts of the platform; your team remains responsible for the configurations, identities, workloads and data assigned to your service model. The assessment names the accounts or subscriptions, environments, services, owners and permitted review methods. A provider certificate does not prove your tenant settings or operating controls.
The benchmark version used is recorded; preview guidance is not silently represented as a final standard.
05
Make the responsibility boundary visible
For each service in scope, record what the provider operates, what your team configures and what a supplier performs for you. Check the service model and the applicable provider documentation rather than applying one division of responsibility to every workload.
| Responsibility question | Record to agree |
|---|---|
| Who maintains the underlying service? | Provider documentation, service commitments and any customer obligations |
| Who controls identities, configuration and data use? | Named internal owners, delegated administrators and approval records |
| Who manages guest systems or application components? | Workload ownership, maintenance procedures and agreed supplier responsibilities |
| Who reviews events and responds to concerns? | Monitoring owner, escalation route and supporting operating records |
| Who approves and verifies a correction? | Change approver, implementation owner, validation method and closure evidence |
06
What we review
| Area | Scoped evidence focus |
|---|---|
| Identity and privileged access | Account ownership, role design, privileged paths, access reviews and emergency access |
| Asset and data understanding | Accounts, subscriptions, workloads, data sensitivity and service dependencies |
| Network and service exposure | Intended access, boundaries and configuration evidence |
| Data protection | Storage access, encryption/key ownership, retention and transfer controls |
| Logging and detection | Event coverage, alert ownership, review records and escalation |
| Change and configuration | Approval, baseline governance and documented exceptions |
| Recovery and supplier responsibility | Backup/recovery evidence, critical dependencies and shared responsibilities |
07
Specific cloud risks to examine
These review questions identify concrete evidence within the agreed environment boundary; they are not a claim of completed testing.
| Review question | Evidence needed |
|---|---|
| Is storage publicly accessible where it should be restricted? | Intended exposure, access settings and owner approval |
| Do identities have permissions beyond their work? | Role design, usage evidence and privilege review |
| Are privileged accounts protected appropriately? | Authentication controls and emergency-access procedures |
| Do network rules permit unintended inbound access? | Intended connectivity and configuration records |
| Do logs cover the relevant activity, with review ownership? | Event coverage, retention, alerts and review records |
| Is sensitive data protected in storage and transfer? | Data classification, encryption controls and key responsibility |
| Are backups and snapshots access-controlled? | Backup/snapshot permissions and recovery evidence |
| Are credentials or secrets exposed in code or configuration? | Secret-management process and approved review evidence |
| Do access policies reflect device and user risks? | Policy scope, exceptions and approval records |
| Do external integrations hold excessive privileges? | Integration permissions, credentials and supplier ownership |
08
How cloud evidence supports assurance
Cloud records support relevant access, change, protection, monitoring and recovery requirements across the frameworks in your scope. We link evidence to each applicable requirement and explain missing records. A shared control does not make every framework identical or establish a blanket compliance result.
09
How CSA STAR Level 2 relates to ISO 27001 and SOC 2
Two STAR Level 2 cloud-security routes are STAR Certification and STAR Attestation. STAR Certification combines ISO/IEC 27001 management-system requirements with the CSA Cloud Controls Matrix (CCM). STAR Attestation combines SOC 2 criteria with the CCM. These are separate from STAR Level 1, which is a self-assessment.
Check which path and cloud-service scope the buyer requests, then confirm the assessment requirements with an eligible independent provider. Mapping cloud evidence for a readiness review does not issue either STAR result; any additional preparation or assessment needs its own agreed scope.
WHAT YOU GET
10
What you receive
| Deliverable | Contents | Decision supported |
|---|---|---|
| Cloud assessment scope | Environments, services, methods, boundaries and access conditions | What was reviewed and what remains outside scope |
| Findings/evidence register | Observations, benchmark references, evidence and business consequence | Which gaps need action or further technical review |
| Responsibility map | Platform, workload, IT, security and supplier owners | Who operates and verifies each control |
| Prioritized remediation roadmap | Actions, dependencies, owners and closure evidence | What engineering should address first |
| Assurance mapping/readout | Relevant framework relationships and limitations | How reviewed evidence supports audit/customer requests |
11
See how observations become an accountable roadmap
Fictional sample — no customer information
Review a fictional Governance Blueprint assessment to see how findings, evidence references, owners and proposed closure conditions can be presented. The sample does not demonstrate technical testing or configuration changes in your cloud environment. Your written scope defines the AWS and Azure services, review methods and outputs.
The sample illustrates presentation. Your engagement scope defines the work.
13
From cloud evidence to an engineering handoff
- 01Confirm the boundary. Identify accounts, subscriptions, relevant services, business dependencies and the evidence owners can provide.
- 02Examine the records. Review the agreed exports, interviews and walkthroughs. Separate an observed configuration issue from a tool alert that still needs validation, an unavailable record or an area that needs specialist technical testing.
- 03Set priorities. Describe the affected control, business consequence, proposed action, owner and dependency. Distinguish a contained configuration correction from a change that needs architecture design and engineering evaluation.
- 04Agree the handoff. The responsible team decides how to implement and validate each change. The roadmap records the evidence needed to close the finding and the conditions for any later review.
Existing native-platform findings can contribute evidence when their scope, date and collection method are known. A tool's alert or score is a starting point for review, not a substitute for understanding the affected service and its business use.
14
Agree how recommendations become operating controls
The assessment identifies who needs to own a correction and how completion can be demonstrated. Production changes, new architecture, infrastructure-as-code development, monitoring operations and incident handling need separately agreed delivery responsibilities. Their access, approval, rollback and validation arrangements should be settled before work begins.
If a later review is needed, agree which findings will be revisited and what updated evidence will be available. A scheduled evidence review does not establish continuous monitoring or an incident-response commitment.
15
Cloud data deserves specific evidence
IBM's 2023 Cost of a Data Breach study reported cloud-stored data in 82% of the breaches it studied. The research covered 553 breached organizations, with incidents occurring between March 2022 and March 2023. This is historical study evidence about breached organizations, not the probability of a breach in your environment.
Your review therefore starts with where data resides, who has access and which records demonstrate the controls in operation.
16
Platform-specific questions
| Platform | Examples to examine within the agreed scope |
|---|---|
| AWS | IAM roles, privileged account protections, S3 access, security groups, CloudTrail evidence, key ownership and recovery records |
| Azure | Entra roles and access policies, storage access, network exposure, logging, key ownership and recovery evidence |
The scope names the actual services and review methods. Findings distinguish observed configuration from controls requiring deeper technical evaluation.
17
Scope and fee
| Scope and fee | The proposed engagement focuses on scoped AWS and Azure services. A written proposal confirms the platforms, environments, fee, delivery and any technical access requirements. Technical implementation is separately defined. |
|---|
18
Cloud review questions
Does this replace a penetration test?
No. Configuration and governance review answer different questions from exploitation testing. Existing technical reports contribute evidence where relevant.
Will you fix settings in production?
Implementation needs its own authorized scope, change approvals and rollback plan. Assessment does not grant write access.
Are all cloud providers included?
The proposal names the platforms and services. An AWS or Azure scope does not automatically include another platform.
Does a benchmark score prove compliance?
No. The findings explain observed controls, scope and limitations. Legal compliance and assurance conclusions require their own process.
19
Planning the review
Can existing security tools contribute to the assessment?
Yes. Bring relevant exports and reports, including their date, environment coverage and collection method. We agree which records are suitable for the review. Tool configuration, deployment and operation require their own scope.
Can the roadmap inform automation work?
It can identify the control objective, owner and evidence an automated check should produce. Writing or deploying infrastructure-as-code and validating automated guardrails are separate engineering activities.
What if the review follows a security incident?
Tell us about the incident and the current response arrangements when discussing scope. Existing incident findings can inform a later governance and evidence review. Active containment, investigation and recovery require an appropriately scoped response service.
Can one review support several assurance requests?
The scope identifies the requirements to which evidence will be mapped. The report records any differences in coverage, testing and evidence depth rather than treating one framework's result as another framework's conclusion.
20
Connect cloud observations to an accountable plan
Bring your environment map, upcoming buyer or audit request and available control owners. We will discuss the appropriate review boundary.
Free 30-minute cloud security strategy call. No obligation.
22
Scope and fee
Fixed fee confirmed after scoping.