Moving infrastructure to the cloud does not make it secure: it changes where the flaws live. Most cloud breaches do not come from a provider failure, they come from a permission configuration someone left open to get something working and nobody looked at again.
Where the provider’s responsibility ends
The shared responsibility model is clear on paper and confusing in practice. The provider is responsible for the security of the cloud; you are responsible for security in the cloud: identities, permissions, configuration, data, network and everything you deploy on top. That is where we work.
What we review
Identity and permissions: over-privileged accounts, unused roles, access keys that have not been rotated in years and escalation paths inside the provider itself. It is the leading cause of cloud incidents.
Exposure: public storage, internet-reachable databases, published management consoles and wide-open security groups.
Network and segmentation: whether a compromised container reaches the production database or stays where it should.
Encryption and key management: at rest, in transit, and who can decrypt what.
Containers and Kubernetes: images, secrets, admission policies and pod privileges.
Infrastructure as code: reviewing the templates, which is where a flaw gets fixed once and for good.
Logging and traceability: whether you could reconstruct what happened after an incident, which is exactly when people discover nothing was being logged.
How we work
1
Real inventory
What is actually deployed, across how many accounts and regions. Forgotten test environments still being billed are a common find.
2
Configuration review
Benchmarked against the provider’s good practice and the relevant CIS Benchmarks.
3
Escalation path analysis
Listing permissions is not enough: you have to see which chain of permissions takes an ordinary account to full control.
4
Technical testing
Within an agreed scope, we verify what can genuinely be reached from outside and from inside.
5
Remediation plan
Prioritised and, wherever possible, expressed as a change in infrastructure as code so it does not reappear.
6
Verification
Retest of the fixes and a baseline to measure drift at the next review.
What you get
Inventory of accounts, services and deployed assets.
Configuration report with prioritised findings and evidence.
Privilege escalation path map.
Remediation plan with the concrete change, in code where possible.
Baseline to measure configuration drift over time.
Who does the work. The same team that audits, not an account manager. Governance, risk and compliance: CISSP, CISM, ISO 27001 Lead Auditor, ENS and Risk Analysis (CCN), certified DPO, CCSP and CDPP (ISMS Forum) and PMP (PMI). On the technical side: OSCP, CRTO II and eWPTX, ranked in the top 1% of the CCN-CERT Atenea platform. We have run compliance projects for crypto exchanges, universities and public administrations.
Questions we get asked
We use a major provider. Is it not secure already?
Their infrastructure is. What you deploy on top is not necessarily. Practically every well-known cloud breach has been a customer configuration error, not a provider failure.
Do you work with AWS, Azure and Google Cloud?
Yes, and with hybrid and multi-cloud environments too, which accumulate the most identity problems because nobody holds the full picture.
Is this the same as a penetration test?
They complement each other. Configuration review finds the misplaced permission; the pentest shows how far you get with it. Usually it is best to start with configuration, which gives more for less.
Does it help with the ENS or ISO 27001?
Yes, and it saves you work: much of the technical evidence an auditor asks for comes straight out of this review.
Review your cloud before someone else does
Half an hour with an auditor to agree accounts, environments and scope.
Phone: +34 686 250 244 (Mon-Fri, 9:00 to 18:00 CET) · Email: info@jaymonsecurity.com
We reply within 2 working hours.
