Turning AWS Security Findings into APRA-Paragraph Narrative with Bedrock

Run Prowler or Security Hub against an AWS account and you get hundreds of findings. They're accurate, technical, and completely unreadable to a risk committee. S3_BUCKET_PUBLIC_READ_PROHIBITED: alarm is a fact. It is not a sentence anyone on a board wants to read.

The hard part of an APRA CPS 234 review was never finding the issues. It's translating "IAM user has AdministratorAccess attached" into "Here is our position against CPS 234 paragraph 21, the evidence, the risk, and the remediation plan." That translation is manual, slow, and the single biggest time-sink I see in a compliance cycle.

So I built the thing that sits in the middle.

Practitioner guidance, not legal or audit advice. AI drafts the narrative; a human owns the sign-off.

The pipeline

The tool is deliberately boring in shape:

Prowler / Security Hub / Config findings
        │
        ▼
  aggregate per CPS 234 control  (status + the failing resources)
        │
        ▼
  Amazon Bedrock (Claude)  →  board-ready paragraph per control
        │
        ▼
  Report: exec summary · control-by-control · evidence · remediation roadmap

Two inputs go in: the findings (a Prowler compliance run) and the framework mapping (which checks evidence which CPS 234 paragraph, plus the rationale and remediation for each control). The tool joins them on the control ID, rolls findings up per paragraph, and hands each control's structured data to the model.

The model never sees a blank page. It gets the control, its status, the specific failing resources, the requirement text, and the remediation guidance — and is asked to write 3–5 sentences for a risk committee. Constrained generation, not free-form. That's what keeps it accurate and stops it inventing findings.

Before and after

Here's a real finding, the raw output of a scan:

control: cps234-21-access-control   status: FAIL
- IAM user has AdministratorAccess policy attached
- IAM Access Analyzer is not enabled

And here's what the model returns, given that plus the CPS 234 context:

Access Management Controls — Non-Compliant. The entity's access management controls do not meet CPS 234 paragraph 21. Evidence shows a user account holding unrestricted AdministratorAccess with long-lived credentials, and no IAM Access Analyzer to detect excessive permissions. These weaknesses create material risk of unauthorised access and account compromise, directly contradicting CPS 234's mandate for controls proportionate to asset criticality. Immediate remediation: revoke AdministratorAccess, transition to role-based access with temporary credentials, and enable IAM Access Analyzer.

Same facts. One is a log line; the other is something a CISO can put in front of a board. The model didn't add anything that wasn't in the findings — it reframed them against the standard.

Why it runs on Bedrock — and in Australia

For an APRA-regulated entity, where the inference happens matters. Sending compliance findings about a regulated environment to an arbitrary third-party API is exactly the kind of third-party risk CPS 234 (and CPS 230) ask you to manage.

Amazon Bedrock offers Australian-resident inference profiles for Claude — the au. profiles keep the request inside AWS Australian regions, under your existing AWS account, IAM, and data agreements. The call is a single Converse API request:

client.converse(
    modelId="au.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system=[{"text": SYSTEM_PROMPT}],
    messages=[{"role": "user", "content": [{"text": control_context}]}],
    inferenceConfig={"maxTokens": 400, "temperature": 0.2},
)

Low temperature, capped tokens, structured input. The findings never leave AWS, and there's no new vendor to put through a third-party assessment.

First-time Bedrock use of Anthropic models requires submitting use-case details once per account — a one-time console step before you can invoke.

The engineering that makes it trustworthy

A compliance tool that hallucinates is worse than useless. Three design choices keep it honest:

• Constrained input. Each paragraph gets only its own findings. The model summarises; it doesn't source.
• A deterministic fallback. The same report can be generated with no LLM at all — straight from the framework's rationale and remediation text. If Bedrock is unavailable, each control falls back to the template version rather than failing. You can run the entire thing offline for air-gapped review, then run it through Claude for polish.
• Manual stays manual. Roughly a third of CPS 234 is governance and process — board accountability, the policy framework, incident-response plans, the 72-hour APRA notification. None of that is observable from an AWS API. The report marks those controls manual and says so, rather than pretending a cloud scan can evidence them. An honest "you must check this yourself" is worth more than a fake green tick.

The full report comes out as an executive summary (automated compliance score plus the count of manual controls), a control-by-control assessment with cited evidence, and a prioritised remediation roadmap.

Where this fits

This is one piece of a set: a Prowler framework and AWS Config conformance pack produce the findings; this tool turns them into the narrative. Findings tell you what's wrong. The narrative tells your board what it means and what you're doing about it — which is the artifact a CPS 234 review actually runs on.

The translation layer between security tooling and the boardroom has always been a person with a spreadsheet at 11pm. It doesn't have to be.

Want the mapping behind it? Grab the CPS 234 → AWS Controls cheatsheet — every control mapped to the AWS service, Config rule, and the evidence that satisfies it.

Primary sources: Amazon Bedrock · Bedrock data protection · APRA CPS 234