Risk, resilience and compliance · AWS · Azure · Continuous compliance
Turn point-in-time audits into continuous assurance. Cloud configuration, findings and policy results flow into one evidence store, are mapped to named controls across several standards, and reach owners and auditors through dashboards and read-only access.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
AWS Config rules and conformance packs evaluate resource configuration continuously and send compliance results to Security Hub with findings from other AWS security services.
Findings from every account in the organisation are aggregated in a delegated administrator account and exported to the evidence collector, with account, resource, time and severity attached.
AWS Audit Manager assessments gather automated evidence for controls such as logging, access and encryption, and hold manual evidence for controls that are procedural, such as a tested restore.
Defender for Cloud reports regulatory compliance and security recommendations for Azure subscriptions, and exports them to the collector.
Azure Policy initiatives enforce and evaluate configuration such as allowed regions, encryption and diagnostic settings. Compliance state is visible in Defender for Cloud and exportable.
Purview Compliance Manager tracks assessments for data protection and information governance, with improvement actions and the evidence attached to them.
The collector normalises records into one schema, computes a hash, timestamps them and writes them once to storage with Object Lock and versioning. Anyone who can change a finding after the fact is outside the production and compliance admin groups.
A control library maps each internal control to the relevant requirement in each standard. A single piece of evidence can support several standards, so teams collect it once.
Dashboards show control status by owner and by standard, trend over time and exceptions. They highlight controls with stale evidence as well as failed ones.
Failed controls become tickets with an owner, due date and either remediation or a documented, approved risk acceptance with an expiry.
Auditors and assessors receive read-only, time-limited access to the evidence they sample, so they see the system of record and not a screenshot pack prepared for them.
| Component | What it does | Why this choice |
|---|---|---|
| AWS Config and Security Hub | Continuous configuration evaluation and aggregated security findings across accounts. | Native, low-effort and organisation-wide, with standards-based scoring. |
| AWS Audit Manager | Maps AWS evidence to framework controls and stores assessment reports. | Reduces manual evidence collection for supported frameworks. Content must still be checked against your scope. |
| Azure Policy and Defender for Cloud | Policy enforcement, regulatory compliance views and recommendations. | Native to Azure subscriptions and management groups. |
| Purview Compliance Manager | Assessments and actions for data protection and information governance. | Common for Microsoft 365 data handling obligations. |
| Evidence collector | Normalises, hashes and stores evidence from every source. | One schema lets one control serve many standards. |
| Evidence store with Object Lock | Write-once, versioned storage with access logging. | Supports integrity of evidence and a defensible audit trail. |
| Control library | Your control catalogue mapped to standards and owners. | Avoids a separate evidence project for every standard. |
| Compliance dashboard and tickets | Status, trends and a path to remediation. | Keeps evidence tied to action and ownership. |
Native tools or a GRC platform
Why. Native tools are close to the data and low in cost. A platform adds workflow, but only helps if the controls are well defined.
Trade-off. Native tools do not cover people and process controls. Plan manual evidence for them.
Continuous or point-in-time evidence
Why. Continuous evidence finds drift early and shortens audits.
Trade-off. More data to store and more alerts to triage. Tune rules to avoid noise.
Where evidence lives
Why. Evidence has value when it cannot be quietly edited.
Trade-off. Additional account structure and access processes.
One control, many standards
Why. Avoids parallel programs for CPS 234, ISO 27001, PCI DSS and SOC 2 that ask for similar things.
Trade-off. Mappings need maintenance when standards change, and mapping is judgement, not equivalence.
Handling exceptions
Why. Accepted risk is visible, reviewed and not forgotten.
Trade-off. Needs governance to avoid becoming a way around controls.
Evidence store is write-once, encrypted with customer-managed keys and has separate access controls. Collectors use read-only roles to sources.
Collection is idempotent and replays from the sources. Evidence store is versioned and replicated.
Event-driven collection, with scheduled sweeps for sources that cannot push.
Config and security service costs grow with resources and rules, so tune scope, retain high-value evidence longer and move older evidence to lower-cost storage.
Owners review control status monthly. The control library is reviewed when a standard changes, and after any incident.
Collect what a control needs and no more, and tier older evidence.
Collectors reach sources through private endpoints and cross-account roles. The evidence account has no inbound internet path. Auditor access is through federated, time-limited sign-in with MFA.
Read-only collection roles, separate custodians for the evidence account, and just-in-time access for auditors. Compliance admins cannot delete evidence. Changes to the control library are reviewed through pull requests.
Evidence may contain configuration details and user identifiers. Classify it, restrict access, retain according to the longest applicable requirement and delete when no longer required. Record the source, time, hash and the control it supports.
| Control | How this design addresses it |
|---|---|
| Information security policy, testing and assurance | Systematic control testing with retained results. CPS 234. |
| Operational risk controls, monitoring and remediation | Control owners, issue tracking and risk acceptance records. CPS 230. |
| Statement of Applicability and control operation | Control library and evidence support ISMS operation and internal audit. ISO/IEC 27001:2022. |
| Essential Eight maturity evidence | Configuration and patch evidence for each strategy. Essential Eight. |
| Logging, monitoring and testing | Logging and review evidence for in-scope systems. PCI DSS v4.0.1 and SOC 2. |
| Integrity of evidence | Object Lock, hashing and access logs for audit defensibility. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| A control fails silently because a collector stopped | Heartbeat checks and an evidence age report that flags stale evidence as a failure. |
| Evidence altered or deleted | Object Lock, separate custodians and alerts on access policy changes. |
| Mappings go out of date | Version the control library and review when a standard is revised. |
| Alert fatigue | Tune rules, use severity and ownership routing, and review noisy controls monthly. |
| Cross-cloud inconsistency | Common schema and a shared control definition, with documented differences. |
| Automated pass given to a control that needs judgement | Mark controls as automated, partly automated or manual, and require attestations where needed. |
Configuration evaluation and security service charges, log and evidence storage, and effort to curate the control library.
Incident response · Regulatory notification
A detection and response design that starts the right notification clocks from one incident record: materiality assessment against tolerance levels, pre-drafted regulator forms, approvals, evidence capture and a post-incident review that feeds back into the risk register.
API security · Tokenisation · Zero trust
A controlled edge for partners, fintech suppliers and SaaS platforms that need regulated data. Each partner is authenticated, authorised per scope, rate limited and logged, sensitive fields are tokenised, and everything is encrypted with keys you hold.
AWS · CPS 230 · Resilience
A technical design that traces each critical operation to the services behind it, sets recovery capability from tolerance levels, replicates to a second region, and proves the result through game days and continuous service-level monitoring.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.