Skip to content
Services
How it works Scope & safety Findings Review desk Blog Write to us
HomeServicesCloud & service security
Cloud & service security

Understand what connects.
Protect what it can reach.

A scoped review of cloud resources, service identities and application-to-infrastructure boundaries. Provider coverage and required access are confirmed before an engagement.

INSIDE THE ASSESSMENT
Permissions connect the layers.An application reaches a service identity, which has separately scoped access to storage and other services.ApplicationAgreed environmentService identityPermission boundaryStorageScoped resourcesServicesExplicit relationships
Permissions connect the layers.
ResourcesIdentityTrust relationships
01 / Where this helps

Understand the connections.
Review the authority.

Illustrative engagement scenarios—not a claim that every provider or resource type is supported.

AppIdentityStorageACCESS IS A RELATIONSHIP
SERVICE PERMISSIONS

One identity.
Several places it can reach.

You are changing a workload identity or connecting a new resource.

The question
Do the agreed service permissions match the application’s intended responsibilities?
Assessment focus
Named identities, relevant resource policies and the trust relationships in scope.
Useful output
Resource-specific observations with the access assumptions and consequences made explicit.
PrivateBoundaryPublicEXPOSURE NEEDS CONTEXT
RESOURCE EXPOSURE

Reachable does not mean
intentionally public.

You need to understand the exposure of selected cloud-backed services.

The question
Which resources should be reachable, by whom and under what conditions?
Assessment focus
Approved resource configurations and selected externally reachable boundaries.
Useful output
Observed exposure interpreted against intended use, with limitations stated.
Service ATrustService BREVIEW BOTH ENDS
ARCHITECTURE CHANGES

A new service.
A different trust boundary.

You are connecting workloads, environments or a third-party integration.

The question
Are service-to-service assumptions consistent with the permissions granted?
Assessment focus
Agreed connections between application identity, cloud resources and service access.
Useful output
A description of the affected relationship and practical remediation priorities.
02 / Access & scope

Agree on the resources.
Then agree on the access.

Cloud assessment scoping guide
AreaCandidate scopeConfirm before testing
Provider & resourcesCandidate scopeNamed cloud accounts, projects, services and resource types.Confirm before testingProvider-specific technical fit and the precise resource inventory.
Identity & permissionsCandidate scopeAgreed workload or service identities and relevant policies.Confirm before testingAccess method, permission level and customer contact responsible for access.
Review modeCandidate scopeConfiguration review and selected validation where authorized.Confirm before testingRead-only versus active checks; actions that are explicitly excluded.
Operational contextCandidate scopeEnvironment, ownership and intended service relationships.Confirm before testingProduction constraints, test windows and escalation arrangements.
Data & evidenceCandidate scopeThe information needed to support scoped observations.Confirm before testingSensitive-data boundaries and any required handling commitments.
03 / Deliberate limits

Access is not blanket permission.

A permission that exists in an account does not automatically authorize every action it could enable.

  1. 01

    Propose the scope

    Name the resources, connections and decisions you want assessed.

    CUSTOMER CONTEXT
  2. 02

    Agree the boundaries

    Define permitted operations, access and operational stop conditions.

    EXPLICIT AUTHORIZATION
  3. 03

    Review & explain

    Our researchers validate findings and explain what the available access did not allow us to assess.

    HUMAN-APPROVED DELIVERY

No implied organization-wide coverage, resilience exercise or unrestricted production testing.

04 / What you receive

Cloud context.
Engineering-ready findings.

A useful observation identifies the resource, relevant identity and intended boundary. It distinguishes a configuration concern from an impact demonstrated within scope.

Explore assessment deliverables ↗
ILLUSTRATIVE STRUCTURE · NOT A CUSTOMER REPORT
ENGAGEMENT OUTPUT

Context. Evidence.
A useful next step.

01

Affected resources

Named services, resource identifiers and the agreed environment.

02

Access assumptions

The identity and permissions relevant to the observation.

03

Evidence & limits

Observed behavior, supporting configuration context and untested assumptions.

04

Remediation & follow-up

Suggested changes and retest status where retesting was agreed.

05 / Before we start

Practical questions.
Clear expectations.

Bring your technical constraints and buyer requirements to the scoping conversation.

Which cloud providers do you support?

Provider and resource-type coverage is confirmed during scoping. Share your environment before assuming a particular provider or service is supported.

Do you need administrator access?

Not by default. We discuss the minimum appropriate access for the agreed review. If access is insufficient, we explain the resulting coverage limit.

Will you change our infrastructure?

Changes are not implied by a review. Any active operation or configuration change must be explicitly agreed before it is performed.

Can you review only a small part of our environment?

Yes, an engagement can be proposed around selected resources or relationships, subject to technical fit. The resulting report does not represent the whole environment.

Is this a compliance certification?

No. Share any contractual or buyer-specific requirements before engaging us so we can establish whether the proposed work is suitable.

LET’S DEFINE YOUR ENGAGEMENT

Bring us your scope.
We’ll discuss the next step.

Share your system, priorities and target date.
Please do not include credentials or sensitive findings.