Security Audit
A fixed-price audit of your environment, cloud or on-prem. You get a prioritized findings report you can act on immediately.
- Fixed price, quoted on the scoping call
- One environment
- Typically one week
- Complete prioritized report
This is a complete standalone engagement. Take the report to your own team and stop there, or ask ZuluSec to turn its findings into the backlog for separate engineering work. Remediation is optional.
Every audit covers the fundamentals attackers actually use: who can access what, what's exposed to the network, whether you'd notice a breach, and where your data can leak. Cloud-native (AWS, Azure, GCP), on-prem, or hybrid, the checklist adapts and the rigor does not. Where you run Kubernetes the cluster is in scope too: RBAC, network policies, control-plane exposure, secrets, and workload hardening.
How the audit is delivered
A practitioner decides what to check and what the answers mean. The evidence is collected by deterministic tooling: run it twice against the same environment and it returns the same findings, so each one is something you can reproduce rather than take on trust. Nothing in your report is generated prose about what might be wrong. Every finding names the resource, the setting, and the evidence it came from.
That is also what keeps the price fixed on a large scope. More systems mostly means more collection, the tooling absorbs that work, and the expensive part remains the part that genuinely needs a person.
Who fixes what the audit finds
The audit is read-only and ends at the report, and plenty of teams take it from there with their own people. If you have nobody to do that, the fixes become the next engagement rather than a new service. Rebuilding what was exposed as infrastructure code, pipelines, and least-privilege roles is Platform Engineering. The segmentation and identity work behind findings that keep coming back is Zero-Trust Architecture. Hardening to a named baseline and producing evidence for a customer or an assessor is Compliance Hardening.
Each is engaged in one of three ways (alongside your team, built for you, or kept running) and quoted from what the report found, so you commit to the smaller number before the larger one.
What the audit does not cover. No exploitation of any finding, no denial of service or load testing, no social engineering or physical access, no third-party SaaS you do not control, and no application source code review beyond secrets and configuration exposure. That last one matters most if your own application is where your risk lives. The same list is in the sample report, and the scope you agree at the scoping call says it in writing.
What the findings report looks like
Here's a representative slice of a report, ranked worst-first. Synthetic environment, no client data. Every finding follows the same shape: what was found, why it matters, the fix, and the effort to do it.
Customer data reachable from the public internet
An S3 bucket holding exported customer records has Block Public Access disabled and a policy that grants read to everyone. Anyone who finds the bucket name can download it, and with no access logging you can't tell whether someone already has.
Fix: turn on account-level Block Public Access, remove the public grant, enable access logging, and sweep for other exposed buckets. Effort: ~2 hours, plus rotating anything that was exposed.
Kubernetes control plane exposed to the internet
The cluster's API server accepts connections from anywhere and the dashboard is publicly reachable. A single leaked or brute-forced token is full cluster control: read every secret, schedule any workload, and pivot into the rest of the account.
Fix: restrict the API server to authorized networks or a private endpoint, take the dashboard off the public internet, enforce least-privilege RBAC, and rotate exposed tokens. Effort: ~half a day.
You wouldn't see a breach in progress
CloudTrail runs in one region only, threat detection is off, and no alert reaches a human. An attacker working in an unlogged region leaves no trail, and even logged activity is nobody's job to catch.
Fix: enable multi-region CloudTrail to a locked-down bucket, turn on GuardDuty, and route findings somewhere a person actually reads. Effort: ~half a day.
Loaded guns that haven't fired yet
Fourteen security groups allow inbound from anywhere on ports the instances currently keep closed, and three IAM roles hold full-admin permissions they have never used. No active exposure today, but each one turns the next small mistake into a big one.
Fix: scope the security groups to known sources and right-size the roles to their real usage. Effort: ~half a day.
That ranking is the point: you get a prioritized list, not a scanner dump. Fix the top of it and you've closed the real risk.
Read a full sample report
The complete 14-page format: executive summary, scope and method, eight findings carrying evidence, fix, and effort, and a sequenced remediation plan. This one is a Standard engagement, so two parts are Standard additions: the storage and backup review behind ZS-01, and section 5. A Baseline report is the same format for one environment. Synthetic environment, no client data.
Engagement options
Baseline
One environment: a single cloud account, subscription, or project, whatever number of services runs in it, or one on-prem site of up to 25 systems. Larger on-prem sites are quoted from the scoping call rather than turned away.
- ✓Identity & access review
- ✓Network exposure & segmentation review
- ✓Kubernetes & container review (where you run it)
- ✓Logging & detection coverage review
- ✓Prioritized findings report, ranked worst first, with the fix and the effort named for every finding
Standard
Up to three environments: cloud accounts, subscriptions, or projects of any size, or on-prem sites of up to 25 systems each, audited as one footprint. More than three, or a larger site, is quoted from the scoping call.
- ✓Everything in Baseline, across every in-scope environment
- ✓Data storage & backup exposure review
- ✓Sequenced remediation plan across the whole footprint, ordered by risk reduction per hour of effort
- ✓Live readout call with your team
Add-on: Vulnerability Assessment
Authenticated vulnerability scanning of everything in scope, external attack surface and internal systems, mapped to publicly known vulnerabilities (CVEs) and dangerous defaults. Findings fold into the same prioritized report. Choose it at the scoping call so it is included in your quote.
This work is quoted as one fixed price after a scoping call, agreed in writing before work starts. Scope is what sets that price, and the systems involved can be established on the call itself, which is why a firm figure can come out of it. There is no hourly meter: the number agreed is the number you pay, and you have it in front of you before you commit to anything.
Book a scoping callFAQ
- How long does it take?
- Baseline is typically delivered within one week of access being granted; Standard within two.
- What access do you need?
- Read-only credentials scoped at the scoping call. For on-prem Baseline audits, a short scoping call happens first to confirm remote access is workable.
- Does Baseline include a remediation plan?
- Every finding in either tier names the fix and the effort, ranked worst first, so a Baseline report is something you can start working through the day it arrives. Standard adds the storage and backup exposure review, the sequenced plan across the whole footprint, and the live readout call. Section 5 of the sample report is that plan.
- The audit finds ten things. Who fixes them?
- Fixing is separate work, and plenty of teams handle it themselves. If you have nobody to do it, the fixes are engaged through whichever service matches the work rather than through a new product. The section above sets out which service covers what.
- Is this a penetration test?
- No. It is a configuration and architecture audit. It finds the misconfigurations and exposures attackers look for, without active exploitation. Add the vulnerability assessment if you also want scanning for known CVEs and unpatched services; for full exploitation testing, ZuluSec can refer a pentest partner.
- Do you review Kubernetes?
- Yes. Where you run Kubernetes (EKS, GKE, AKS, or self-managed), the audit covers cluster posture: RBAC, network policies, control-plane exposure, secrets, and workload hardening. One cluster is included per environment; large multi-cluster fleets get custom scope at the scoping call.
- Is my environment too big for these tiers?
- Probably not, and the sizing rule is simple. The system count applies to on-prem sites only: the standard tiers cover sites up to roughly 25 servers and network devices. A cloud account is one environment however many services run inside it, so forty services in one AWS account is a Baseline, not an overage. Separate accounts do each count, including non-production ones, so a prod, a staging, and a CI account is three environments and lands in Standard. Larger on-prem sites and bigger fleets are not turned away, they are quoted from the scoping call to reflect the real work.
- What if there are more than three environments?
- That needs custom scope so the report stays thorough instead of thin. It gets quoted properly from a call or an email describing the footprint.
- How is this different from the Compliance Technical Gap Assessment?
- The audit asks what an attacker would find. The gap assessment asks what a named baseline requires, control by control, because a DISA STIG, a CIS Benchmark, or a customer questionnaire asks a different question than whether exposure exists. With a compliance obligation or a questionnaire on your desk, start with Compliance Hardening. To know where you stand generally, start here. You rarely need both.