Cloud security & compliance
Most cloud security reports end where the engineering starts. Calvrix reviews an AWS, Azure, or GCP estate against the benchmarks buyers are actually asked about, then writes the remediation as infrastructure-as-code, in the same repositories your platform already lives in.
What we review against
How the work is shaped
Three engagements, in order. Each one is worth buying on its own, and each one ends at a defined point rather than rolling into the next by default.
Two to three weeks, fixed scope, fixed fee, read-only access. Output is a prioritised findings register with the blast radius written out for each entry, not a console export with 1,400 rows at “medium”.
The remediation, built. Preventive guardrails as code, identity rebuilt to least privilege, logging centralised and made immutable. Every control lands in your repository with the review attached.
Posture held after the project ends. Drift detection, an access-review cadence, patch and upgrade discipline, and a restore actually tested each quarter rather than assumed.
Capability surfaces
Every item below is work we do with our hands in the estate. Where a control needs a product we do not resell it and we do not take margin on it. We tell you which one fits and we configure it.
A read-only assessment of the estate against CIS and the cloud vendor's own security benchmark. Every finding names the blast radius, an owner, and the remediation as we would build it.
The highest-yield finding class in every estate we have reviewed. Standing admin, role sprawl, dormant credentials, over-broad cross-account trust, and secrets living somewhere they should not.
Delete every static cloud credential from CI: usually the single largest reduction in blast radius available to a platform team, and about a week of work. Short-lived OIDC federation replaces the keys in pipeline variables, and third-party actions are pinned to a digest rather than a moving tag.
Controls that make the wrong thing impossible instead of detectable afterwards. Organisation policy expressed as code, reviewed as code, and enforced before the resource exists.
Cluster posture brought to a defensible baseline: what a pod may do, what it may reach, and what images are permitted to run at all.
Public endpoints audited against whether they need to be public. Private-by-default connectivity, and egress treated as a control surface rather than an open door.
The evidence layer. Centralised control-plane logs, immutable retention, and a window scoped to the questions an assessor actually asks: shipped into whichever SIEM you already own.
Immutable, isolated backups, an explicit blast-radius analysis, and a restore that has actually been performed, timed, and documented. An untested backup is a belief, not a control.
What we do not do
Security is a field where the accreditation matters and the staffing model is visible from the outside. These four are outside ours, and we would rather you read that here than discover it in week three.
Buyers ask for CREST or NCSC CHECK accreditation by name, and we hold neither. We can work alongside an accredited testing firm, brief them on the estate, and remediate what they find, which is the half we are good at.
We build the detection plumbing: the logs, the retention, the pipeline into your SIEM. We do not put analysts on a console around the clock. If you need eyes on glass at 3am, you need an MDR provider, and we will help you specify one.
Board reporting, risk registers, and security strategy are a leadership role, not an engineering one. We will give your CISO the technical evidence and the remediation plan. We will not sit in the chair.
We engineer and evidence the technical controls behind ISO 27001, SOC 2, and Cyber Essentials Plus. We are not the certification body and we cannot audit our own work: your assessor stays independent, which is the entire value of having one.
Why this team
How engagement works
A security engagement starts with a fixed-scope, fixed-fee review against read-only access, two to three weeks depending on the size of the estate. Remediation is quoted after the findings exist, never before: a remediation quote written ahead of the review is a guess with an invoice attached, and it is always the wrong shape.
// start the conversation · [email protected]
Frequently asked
A fixed-scope, fixed-fee assessment of an AWS, Azure, or GCP estate against CIS Benchmarks and the cloud vendor’s own security baseline, run read-only over two to three weeks. The deliverable is a written findings register: blast radius, owner, and the remediation as we would build it, not a console export.
We hold neither CREST nor NCSC CHECK accreditation, and buyers ask for those by name. We work alongside an accredited testing firm: we brief them on the estate, and we remediate what they find. Configuration review and penetration testing are different disciplines, and one supplier doing both usually does one of them badly.
No. We build the detection layer: centralised control-plane logs, immutable retention, and the pipeline into whichever SIEM you already own, but we do not put analysts on a console around the clock. If that is what you need, you need an MDR provider, and we will help you specify and integrate one.
No. The review runs against a read-only role scoped to configuration and control-plane metadata. Nothing is installed, no change window is needed, and we do not read application data. The role is documented before it is created and revoked when the review closes.
No. We are not a certification body and we do not audit our own work. We engineer and evidence the technical controls behind it (access control, logging, key management, segmentation, backup and recovery) and produce the artefacts your assessor asks for. Your assessor stays independent, which is the point of having one.
Removing long-lived cloud credentials from CI. Static access keys in pipeline variables are the most commonly exploited path into a cloud estate and the easiest to close: short-lived OIDC federation replaces them, third-party actions get pinned to a digest rather than a moving tag, and the blast radius collapses. About a week of work.
No. Provenance proves where an artefact came from; it does not prove it is safe: a build system reached in trusted context can produce valid, correctly attributed attestations for compromised packages. An SBOM and provenance are inventory and evidence. What reduces the risk is separate: pinned dependencies, scanning as a gate, no long-lived credentials.
No. Backup sits outside the five technical controls of Cyber Essentials. Certification and recoverability are different things, and insurers treat them that way: a cyber policy application asks how recently you tested a restoration. We engineer the controls behind Cyber Essentials Plus, and we test the restore separately, because the scheme does not.