The situation
Kewdale Systems runs a case-management platform for a Commonwealth agency out of a leased data centre in Perth. About 90,000 active case files, 14TB of scanned correspondence, a 400GB PostgreSQL database, six application servers, and an internal roster tool somebody stood up two years ago and nobody has touched since.
The case data is classified PROTECTED. The agency’s next contract requires the platform to be run against the Australian Government’s Information Security Manual, an IRAP assessor is booked for February, and the whole estate is moving into the Sydney Region before then.
Three things are on the table. The data has to be encrypted, and somebody has to be able to say precisely who can decrypt it. The finance director, who signed the data-centre lease, has asked why a shared building in New South Wales is safer than a cage he can walk into. And every service in the design has to be checked against the compliance programme the platform is assessed under, which turns out not to be a formality.
What actually matters
Two questions get run together whenever encryption comes up, and separating them settles most of this. The first is whether the data is encrypted. The second is who can decrypt it. An assessor spends about a minute on the first and the rest of the morning on the second, because the algorithm has never been the weak part. Where the key material lives, whose policy governs its use, and whether each use leaves a record: those are the properties to choose between.
Encryption at rest is what makes a disk, a backup tape or a copied snapshot useless to whoever ends up holding it. Encryption in transit is what stops something on the network path reading a case file as it travels. A platform can do one perfectly and still lose the data through the other, so both get answered separately. At rest also reaches further than people expect: on RDS it covers the storage, the logs, the automated backups, the snapshots and the read replicas together.
Most of these settings are made once, at creation, and are awkward afterwards. An unencrypted EBS volume cannot be encrypted in place; it takes a snapshot and a new volume. An RDS instance can only be encrypted when it is created, and retrofitting means a snapshot, an encrypted copy of it, and a restore. A migration is therefore the cheapest moment in the platform’s life to get this right, because every resource is being created anyway. The same reasoning favours account-wide defaults over per-resource discipline, since a control that has to be remembered is a control that gets missed on a Friday afternoon.
Key choice carries a blast radius worth thinking about before the first key is created. One key for everything makes a tidy diagram and a bad failure: disabling it, or losing access to it, stops every workload encrypted under it at once. On RDS, losing access to the key puts the instance into a recoverable inaccessible state for seven days and a terminal one after that. Keys drawn around data domains keep an accident inside one domain.
The last property is the one that gets skipped. A compliance claim covers a named list of services, not the account in general, so the shape of the estate matters as much as its configuration. A service can be correctly encrypted, sensibly designed and still sit outside the assessment the contract depends on.
What we’ll filter on
- Whether the control protects data at rest, in transit, or both.
- Who holds the key material, and whose policy governs its use.
- Whether each use of the key is recorded in CloudTrail.
- Whether it is on by default, or has to be set at creation and cannot be changed afterwards without copying the data.
- Whether the service is on the in-scope list for the compliance programme the workload is assessed against.
The landscape
TLS and AWS Certificate Manager cover the transit half. ACM issues and renews the public certificates that terminate TLS on Elastic Load Balancing, Amazon CloudFront, Amazon API Gateway and a handful of others. A public certificate used exclusively with an ACM-integrated service carries no charge, and ACM starts the renewal up to 60 days before expiry without anyone doing anything. Exportable public certificates are a separate, billed option, for terminating TLS somewhere ACM does not reach.
Server-side encryption means the service encrypts the data before writing it to disk and decrypts it on the way back out. Amazon S3 has applied server-side encryption with Amazon S3 managed keys, SSE-S3, as the base level for every new object since 5 January 2023, at no additional cost. Changing the bucket’s default to SSE-KMS moves key custody into AWS Key Management Service, where a key policy you write governs who may use the key and CloudTrail records every call. DSSE-KMS applies two independent layers of KMS encryption for workloads whose controls call for it. SSE-C has the caller supply the key on every request, which means storing and protecting it somewhere else entirely.
Client-side encryption happens before the data reaches AWS. The service stores ciphertext it cannot read, and the encryption process, the keys and the tooling are all yours to run. It is the answer when a control says the provider must not be able to decrypt the data, and it comes with the corresponding obligation: a lost key means lost data, with nobody to appeal to.
AWS KMS holds keys in three forms, and telling them apart is most of the ground here. An AWS owned key sits in an AWS service account, costs nothing, and cannot be viewed, audited or managed by you. An AWS managed key sits in your account with an alias like aws/ebs, is free to hold, rotates automatically every year, and is controlled by the service rather than by you. A customer managed key is one you create, write the policy for, enable, disable, rotate and schedule for deletion, at a monthly charge plus usage. Only the last gives an assessor a document saying who is permitted to decrypt.
AWS CloudHSM gives you single-tenant hardware security modules, validated to FIPS 140-2 level 3 or FIPS 140-3 level 3 for clusters in FIPS mode. The data plane is end-to-end encrypted and not visible to AWS, so user management inside the cluster is yours, and so is the operational load. It suits a control that names dedicated hardware; everything else is better served by KMS.
Amazon EBS encryption uses KMS keys, protects the data at rest and the traffic between the instance and the volume, and can be switched on as a per-Region account setting. Once enabled for a Region it applies to new volumes and snapshot copies, and it cannot be turned off for individual volumes in that Region. It has no effect on volumes that already exist.
Amazon RDS encryption is enabled at creation and covers the underlying storage, logs, automated backups, snapshots and read replicas. Either an AWS managed key or a customer managed key protects it. Encryption cannot be turned off afterwards, and it cannot be turned on afterwards either.
AWS Secrets Manager stores database credentials, API keys and tokens, and rotates them on a schedule, which is what separates it from everything else here. It costs USD$0.40 per secret per month and USD$0.05 per 10,000 API calls. AWS Systems Manager Parameter Store stores configuration data, and stores secrets as SecureString parameters encrypted with a KMS key. Standard-tier parameters carry no additional charge and there is no built-in rotation.
AWS Artifact is where the compliance evidence lives: SOC reports, ISO certifications, PCI attestations and the IRAP PROTECTED package, all free of charge, along with the agreements an account holder reviews and accepts. The companion piece is the AWS Services in Scope by Compliance Program page, which lists, programme by programme, which services the most recent assessment covered.
Evaluation
Side by side
| Choice | Protects | Who holds the key | On by default | Key use in CloudTrail |
|---|---|---|---|---|
| TLS with an ACM certificate | In transit | AWS, for an ACM-issued certificate | ✗ | ✗ |
| SSE-S3 | At rest in S3 | AWS | ✓ | ✗ |
| SSE-KMS, AWS managed key | At rest | KMS, under a service-controlled policy | ✗ | ✓ |
| SSE-KMS, customer managed key | At rest | KMS, under your policy | ✗ | ✓ |
| DSSE-KMS | At rest, two layers | KMS, under your policy | ✗ | ✓ |
| SSE-C | At rest | You, supplied on every request | ✗ | ✗ |
| Client-side encryption | At rest and in transit | You, outside AWS | ✗ | ✗ |
| EBS encryption by default | At rest, and instance to volume | aws/ebs, or a key you name |
✓ per Region, once set | ✓ |
| RDS encryption at creation | Storage, logs, backups, replicas | AWS managed or customer managed | ✗ | ✓ |
| CloudHSM | Whatever you build on it | You, in single-tenant hardware | ✗ | ✗ |
Which service holds which kind of secret
| Service | What it holds | Rotation | Worth knowing |
|---|---|---|---|
| AWS KMS | Encryption keys, used by other services | Annual for AWS managed keys, optional for customer managed | A customer managed key carries a monthly charge |
| AWS CloudHSM | Your own keys, in hardware only you use | Yours to run | FIPS 140-3 level 3 in FIPS mode; the data plane is not visible to AWS |
| AWS Certificate Manager | TLS certificates | Automatic, starting up to 60 days before expiry | Free with ACM-integrated services |
| AWS Secrets Manager | Database credentials, API keys, tokens | Built in, on a schedule | USD$0.40 per secret per month |
| Parameter Store | Configuration, and secrets as SecureString | None built in | Standard-tier parameters carry no additional charge |
The design against the assessment
The IRAP assessment covers in-scope services in the Sydney and Melbourne Regions, and the list of those services was last updated on 2 July 2026. Checking the design against it takes ten minutes and produces one surprise.
| Service in the design | On the IRAP in-scope list |
|---|---|
| Amazon EC2 and Amazon EBS | ✓ |
| Amazon S3 | ✓ |
| Amazon RDS | ✓ |
| AWS Key Management Service | ✓ |
| AWS Certificate Manager | ✓ |
| AWS Secrets Manager | ✓ |
| Amazon Lightsail, running the roster tool | ✗ |
The solution
Start with transit, because it is the least contentious part. Request a public certificate from ACM for the platform’s domain, validate it through DNS, and attach it to the load balancer. Renewal runs by itself from up to 60 days before expiry, which removes the annual scramble that has caused two outages in the leased data centre. Connections to the PostgreSQL database use TLS as well, so that the leg between the application servers and RDS is covered rather than assumed.
At rest, the migration does most of the work if the order is right. Turn on EBS encryption by default in the Sydney Region before a single instance is launched, so that every volume and every snapshot copy created during the move is encrypted from the moment it exists. Create the RDS instance with encryption enabled, since that setting cannot be added later; the migration creates a new instance anyway, so the awkward snapshot-copy-restore path is avoided entirely. For the 14TB of scanned correspondence, set the bucket’s default encryption to SSE-KMS with a customer managed key. Objects already in a bucket are not re-encrypted when the default changes, so anything copied across before the change is rewritten with an S3 Batch Operations copy job.
Use a customer managed key rather than an AWS managed one for the case data, and draw the keys around data domains rather than having one for the estate. The reason is what an assessor can be handed: a key policy naming exactly which roles may decrypt, and a CloudTrail record of every decrypt call against it. An AWS managed key is free and adequate for the roster database and the internal metrics volumes, where nobody is going to ask that question. CloudHSM stays off the design. Nothing in the ISM controls that apply here names dedicated single-tenant hardware, and choosing it would mean running key infrastructure the company has no one to operate.
Credentials go into Secrets Manager with rotation scheduled, which retires the database password that has been in a configuration file since 2023. Connection strings, endpoint names and feature flags go into Parameter Store standard tier at no additional charge, with anything sensitive stored as a SecureString parameter. The separation is simple to hold onto: rotation on a schedule means Secrets Manager, configuration means Parameter Store.
Client-side encryption is considered and left out. No control on this platform says AWS must be unable to read the case files, and adopting it would move key management, key distribution and key recovery into a team of four people. Where a control does say that, the calculation changes and the obligation comes with it.
What the finance director is actually asking
The cage question deserves an answer rather than a brush-off, because the underlying instinct is sound: control usually comes from proximity. What changes in AWS is which half of the work the company is responsible for. AWS is responsible for the hardware, software, networking and facilities that run the cloud services. Physical and environmental controls are inherited in full, which means Kewdale Systems stops writing them, testing them and evidencing them, and starts pointing at an assessment report someone else paid an assessor to produce. The cage in Perth has never been through an IRAP assessment. The Sydney Region has, and the letter is downloadable from Artifact this afternoon.
The second part is what the company can now do that it could not before. Encryption at rest is available on every storage service in the design as a setting, with no key infrastructure to stand up. The quote for two HSM appliances for the Perth site came in at AUD$118,000 before anybody was hired to run them, and the project was shelved in 2024; the equivalent control in the new design is an account setting and a key policy. Every use of that key lands in CloudTrail, so the question “who decrypted this case file, and when” has an answer for the first time. And the controls apply to the estate rather than to the servers currently in it: a bucket created next year in the same account inherits the encryption defaults without anyone remembering the decision that produced them.
None of that makes the platform secure by itself. The data, the access rules, the guest operating systems and the encryption choices all stay on the company’s side of the line. What moves is the half that was consuming the most effort for the least differentiation.
The service that is out of scope
The roster tool runs on Amazon Lightsail, and Lightsail is not on the IRAP in-scope list. AWS is explicit about what that does and does not mean: “If a service is not currently listed as in scope of the most recent assessment, it does not mean that you cannot use the service.” The judgement belongs to the customer, and it turns on what the service touches. A tool holding no PROTECTED data is one conversation with the assessor; this one holds staff names against case identifiers, which puts it squarely in the assessment’s path.
So the tool moves onto EC2 in the same account, with an encrypted volume and the same key policy as everything else, and the Lightsail instance is shut down. The decision is written up, because next February the question will be asked again by somebody who was not in the room. Two adjacent habits come out of the same finding. The list is dated, so it is read again before each assessment rather than trusted from memory: generally available features of a service are reviewed at the next assessment opportunity, which also means a preview feature of an in-scope service is not covered. And scope is regional, so a copy of the case data landing in Singapore for convenience would fall outside an assessment that covers Sydney and Melbourne.
Worked example
An officer at the agency opens a scanned letter from 2021. The browser connects over TLS to the load balancer, which terminates it with the ACM certificate renewed six weeks ago without a ticket being raised. The application server looks up the record in RDS over a TLS connection, using a credential Secrets Manager rotated last Sunday.
The document itself is an S3 object encrypted under SSE-KMS. Fetching it calls KMS to decrypt the data key, KMS checks the key policy for the application role, and the call is written to CloudTrail with the role, the time and the object. The plaintext exists in the application’s memory and travels back to the officer inside the same TLS session. Nothing unencrypted touches a disk at any point, and the audit trail names who read a case file that has been sealed for four years.
Overnight, RDS takes its automated backup. Because the instance was created with encryption enabled, the backup is encrypted under the same key, as are the snapshots and the read replica in the second Availability Zone. Nobody configures that separately.
Run the same document through the roster tool as it was, and three of those sentences stop being true. There is no key policy naming who may decrypt, no CloudTrail record of a decrypt call, and no assessment covering the service holding it. The encryption question and the scope question turn out to be the same question asked from two directions.
What’s worth remembering
- Encryption in transit is TLS on the connection, encryption at rest is the data on disk, and on RDS “at rest” covers the storage, logs, automated backups, snapshots and read replicas together.
- Server-side encryption has the service encrypt and decrypt for you; client-side encryption happens before the data reaches AWS, and the keys, tools and recovery are then yours alone.
- S3 applies SSE-S3 to every new object with AWS holding the key, while SSE-KMS moves custody into a key whose policy you write and whose every use appears in CloudTrail.
- KMS creates and controls keys as a managed service, CloudHSM gives single-tenant FIPS-validated hardware, ACM issues and renews TLS certificates, Secrets Manager stores and rotates credentials, and Parameter Store holds configuration with SecureString for the sensitive parts.
- What a customer inherits from AWS is the physical, hardware and facility half of the work, already assessed, with the reports downloadable from AWS Artifact rather than produced in-house.
- A compliance programme covers a named list of services in named Regions, published on the AWS Services in Scope page, so check it before designing a regulated workload and read it again when the estate changes.