When you need it
Your cloud writes audit logs, but nobody reads them. If someone signed in as root tonight, switched off logging or made a storage bucket public, you would find out weeks later, if at all.
What sets the quote
- One cloud per baseline (AWS, Microsoft Azure or Google Cloud). A second or third cloud is quoted after sizing.
- A standard scope has about 15 alert rules and a larger one about 25, all for high-risk control-plane events.
- Each rule routes to up to 2 destinations: an on-call tool, a ticket system or chat.
- On AWS, up to 4 regions in use are included, because the rules must catch events in every region.
What changes
- A break-glass or root sign-in, a guardrail change or storage made public raises an alert for the people who own the response.
- Every rule has been triggered on purpose, so you know it fires and where the alert lands.
- Whoever receives an alert has a runbook that says what to check first and who decides.
- Audit logs from the whole organisation are collected in one place, and switching them off raises an alert.
What you get
- Central audit log collection: an AWS organisation trail, the Azure Activity log exported through diagnostic settings, or a Google Cloud organisation-level aggregated log sink
- About 15 or 25 alert rules as code, for break-glass or root sign-in, IAM and guardrail changes, public exposure of storage or services, key deletion being scheduled and logging being disabled
- High-severity findings from GuardDuty, Defender for Cloud or Security Command Center routed the same way, where these services are on
- A test record for every rule, showing the event we triggered and the alert that arrived
- A runbook for every rule, covering what it means, what to check first and who decides
- Routing to up to 2 destinations, such as PagerDuty, Jira, Microsoft Teams or Slack
- A handover session with the people who receive the alerts
What we cover on each cloud
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Central audit logs | Organisation trail in CloudTrail | Activity log through diagnostic settings, plus Entra ID sign-in logs and Key Vault logs where rules need them | Cloud Audit Logs through an organisation-level aggregated log sink, plus Cloud Identity login audit logs shared with Cloud Logging |
| Alert rules | EventBridge rules on CloudTrail events | Azure Monitor alerts, or Microsoft Sentinel analytics rules where Sentinel already runs | Log-based alerts in Cloud Logging |
| Findings routed too | GuardDuty findings through EventBridge | Defender for Cloud security alerts | Security Command Center findings |
This is not 24/7 monitoring. Alerts go to your own team during the hours it covers. If you need someone to respond out of hours, the 24/7 critical cover add-on to a care plan can take these alerts, with agreed response times, not fix times.
Not included
- 24/7 security monitoring (SOC or MDR)
- Detection inside workloads, endpoints or application logs
- Incident investigation and forensics
- Cloud charges for log storage, GuardDuty, Defender for Cloud, Microsoft Sentinel or Security Command Center
What we need from you
- AWS: AdministratorAccess in your security tooling account, and a short session with a management account admin to set up the organisation trail.
- Azure: Monitoring Contributor and Resource Policy Contributor at the root management group, and an Entra Security Administrator to export sign-in logs with us.
- Google Cloud: Logs Configuration Writer at organisation level and Monitoring Editor on the logging project.
- An owner for each destination, and 2 hours with the people who will receive the alerts to review the runbooks.
How it works
Free 30-minute call, then a written fixed quote.
Review the current audit logging and agree the rule list, destinations and owners.
Build log collection, rules and routing as code, then trigger every rule on purpose to prove it fires.
Write the runbooks, tune noisy rules after the first live alerts and hand over.
At a glance
- Duration
- 2–4 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
Zero Trust assessment
In 1–2 weeks, a review of identity for people, devices and workloads, cloud guardrails and CI/CD, with every control checked as declared, refused and in effect, ending in a maturity rating per area and a roadmap.
Threat modelling workshop
A STRIDE threat model of one system or major feature, built with your team in two half-day sessions over one to two weeks, with a data-flow diagram, trust boundaries and prioritised mitigations in your backlog.
OS hardening baseline
Linux and Windows Server hardened to CIS Benchmarks Level 1 in two to six weeks, built as code with golden images, enforced settings, drift checks and compliance evidence for every host.