Our Microsoft 365 assessment has been the only platform review we sold, which left everything else in your estate unexamined. This covers AWS, Azure and Google Workspace to the same depth: identity, configuration, exposure, logging, and a hardening plan ordered by what an attacker would reach first.
A configuration and identity review of your cloud environments, producing a prioritised hardening plan. Read-only throughout, with no changes made to your environment and no agents installed.
Cloud breaches are overwhelmingly configuration and identity failures rather than platform vulnerabilities: an over-permissioned role, a storage bucket exposed during a migration, a service account with no expiry, logging that was never enabled. These are invisible from inside the console unless someone goes looking, and the shared responsibility model means the provider will not find them for you.
Scoped by platform and account count. Most organisations have more cloud footprint than they expect once shadow subscriptions and legacy accounts are enumerated.
Users, roles, groups, service accounts and federation. Over-permissioned identities, unused credentials, standing privileged access, absent or weak multifactor enforcement, and the privilege escalation paths that follow from how roles are actually chained.
Platform configuration against the provider's own benchmarks and CIS guidance: compute, storage, networking, database, container and serverless services. Findings are verified rather than reported straight from a scanner.
Publicly reachable storage, databases and endpoints. Encryption at rest and in transit. Where personal data resides across regions, and what that means under PDPA cross-border transfer expectations.
Whether the logs you would need after an incident exist, are retained long enough, and reach somewhere anyone looks. Detection coverage against common cloud attack techniques, and the gaps between what is collected and what is alerted on.
Security groups, firewall rules, network segmentation, exposed management interfaces and connectivity between cloud and on-premises. The rules that were opened temporarily and never closed.
Findings ranked by exploitability and blast radius rather than by scanner severity, with concrete remediation steps, effort estimates and owners. Support implementing the fixes where your team wants it.
Enumeration routinely surfaces subscriptions, accounts and workloads nobody was tracking, which is where the worst findings tend to live.
A scanner produces hundreds of medium findings. This produces a short ordered list based on identity paths and actual exposure, which is what a small team can act on.
Most organisations cannot state precisely where the provider's responsibility ends and theirs begins for each service they use. The report does.
The evidence produced feeds directly into ISO 27001, SOC 2, BNM RMiT and Cyber Security Act obligations rather than being a separate exercise.
The assessment is read-only. No agents, no changes, no production risk, and no requirement to grant standing write access to a third party.
Findings are walked through with your engineers so the same misconfiguration does not reappear next quarter, and the Cloud Security and DevSecOps courses are available where deeper capability is needed.
Identifying every account, subscription and tenant in scope, including the ones outside central IT's inventory.
Granting time-bound read-only access, scoped precisely, with the access model documented and revoked at the end of the engagement.
Benchmark and configuration analysis, followed by manual review of identity relationships and privilege paths, which tooling consistently misses.
Verifying which findings are genuinely reachable and what an attacker could chain together, so the ranking reflects reality.
Findings presented to your engineers and to management separately, because the two audiences need different levels of detail.
Optional support closing findings, followed by a re-test of the items that mattered so closure is evidenced.
Every account, subscription and tenant found, with ownership and purpose where determinable.
Prioritised findings with evidence, exploitability rationale and concrete remediation steps for each.
Over-permissioned identities and the escalation paths available from them, illustrated rather than listed.
Publicly reachable resources, encryption status and where personal data resides across regions.
What is collected, what is retained, what is alerted on, and what would be missing after an incident.
Sequenced remediation with effort estimates and owners, plus an executive summary for management.
We do not resell products, so nothing here is shaped by a vendor margin. The recommendation is whatever your risk and your budget actually justify, including telling you that you do not need the engagement yet.
Findings come with a sequence, an owner and a realistic effort estimate, sized to the team you have rather than the team a framework assumes. A report that cannot be acted on is an expense, not a control.
Our people have carried the obligation internally, not only audited it. That shows up in what we consider proportionate, and in how much documentation we think you genuinely need.
Work is grounded in Malaysian law and regulator expectation, from the PDPA and the Cyber Security Act 2024 to Bursa, BNM and SC requirements, rather than translated from a European or American template.
Where an engagement includes training, the training component is structured to be HRD Corp SBL-Khas claimable, which changes what the programme costs you in practice.
AWS, Azure and Google Cloud, plus Google Workspace. Microsoft 365 is covered by its own dedicated assessment, and organisations running both usually scope them together.
No. The assessment is read-only throughout, using time-bound access scoped to what the review requires. The access model is documented and revoked at the end of the engagement.
No. A penetration test attacks what is reachable from outside. This reviews configuration and identity from inside, which finds a different and largely non-overlapping set of problems. Organisations serious about cloud security generally need both.
A tool produces findings continuously and indiscriminately. This validates which findings are genuinely exploitable, analyses the identity and privilege relationships tools handle poorly, and returns a short ordered list a team can actually work through. Where you already run a tool, we work from its output rather than duplicating it.
For a single platform with a handful of accounts, typically one to two weeks. Larger or multi-cloud estates take longer, driven mostly by the enumeration phase and by how quickly read-only access can be arranged.
Yes. The evidence produced maps to ISO 27001 Annex A technological controls, to SOC 2 criteria, and to the risk assessment expectations under BNM RMiT and the Cyber Security Act 2024. We can present findings mapped to whichever framework you are working against.
Optionally. Many clients remediate internally using the report and bring us back for a re-test. Where your team lacks capacity or specific expertise, we can support the remediation directly.
Tell us which platforms you run, roughly how many accounts or subscriptions, and whether this is driven by a certification, a customer question or a board concern. We will come back with scope, timeline and a fixed quotation.
