April 4, 2026 · Tim Fraser, Cloud Operations Lead

AWS Security Checklist for FinTech Companies

Generic AWS security checklists tell you to enable CloudTrail and use MFA. That's table stakes. If you're running a FinTech platform — processing payments, holding customer financial data, operating under regulatory scrutiny — you need controls that go beyond the basics.

This checklist covers what FinTech specifically needs to get right on AWS, organised by category with practical actions.

Identity and access management

Enforce MFA everywhere. Not just the root account — every IAM user, every federated login. Use hardware security keys (FIDO2) for admin accounts, not SMS-based MFA. SMS can be intercepted through SIM-swapping attacks, which FinTech companies are disproportionately targeted by. Eliminate long-lived access keys. Every long-lived key is a credential that could be leaked in a code commit, a laptop theft, or a phishing attack. Replace them with IAM roles that provide temporary credentials. For CI/CD pipelines, use OIDC federation instead of storing AWS keys in your build system. Implement least privilege with boundaries. Use IAM permission boundaries to set a ceiling that even administrator-created roles can't exceed. This prevents privilege escalation — a developer can't create a role that's more powerful than what the boundary allows. Review access quarterly. Pull the IAM credential report, check for users who haven't logged in within 90 days, and deactivate unused access keys. Auditors will ask when you last reviewed access, and "we don't have a regular schedule" is the wrong answer.

Encryption

Encrypt everything at rest. EBS volumes, RDS databases, S3 buckets, DynamoDB tables, SQS queues. Use KMS customer-managed keys where you need to control key policy and rotation. For RDS, encryption must be enabled at creation — you can't retroactively encrypt without restoring from an encrypted snapshot. Enforce encryption in transit. All load balancers should terminate TLS. Internal service-to-service communication should also use TLS — don't assume that traffic inside your VPC is safe. Rotate and restrict KMS keys. Enable automatic annual rotation on customer-managed keys. KMS key policies should specify exactly which IAM roles can encrypt and decrypt — a policy that allows kms:* for the entire account means any role can access your customer data.

Network security

No databases in public subnets. RDS instances and Elasticache clusters should be in private subnets with no internet gateway route. This is a common finding in security assessments. Restrict security groups to specific ports and sources. A rule allowing 0.0.0.0/0 on port 443 on a load balancer is reasonable. The same rule on port 22 to an EC2 instance is a finding auditors will flag immediately. Use VPC endpoints for AWS services. S3, DynamoDB, SQS, and KMS can be accessed via VPC endpoints, keeping traffic off the public internet and reducing your attack surface. Segment payment processing. Payment components should be in a separate subnet or VPC. Only the specific services that need to communicate with payment processing should be able to reach it.

Logging and monitoring

CloudTrail in all regions. Not just ap-southeast-2. An attacker may operate in a region you don't normally use. Log to a centralised S3 bucket in a separate account with versioning and MFA delete enabled — if an attacker can delete your logs, you lose the ability to investigate. Set up GuardDuty. It's inexpensive and catches things you won't notice in CloudTrail: unusual API call patterns, cryptocurrency mining, compromised credentials from unfamiliar locations. Enable it in every region. Alert on high-severity events. Set up EventBridge rules for root account usage, IAM policy changes, security group modifications, and CloudTrail configuration changes. These should page someone, not sit in an email inbox.

Incident response

Have a documented, tested plan. A concise runbook covering: who to contact, how to isolate a compromised instance, how to revoke leaked credentials, how to preserve evidence, and who needs to be notified. Run a tabletop exercise at least annually — walk through a real scenario and see if the team can execute it. Know your notification obligations. Under APRA CPS 234, you must notify the regulator within 72 hours of a material incident. Under the Privacy Act, notifiable data breaches must be reported to the OAIC. Know these timelines before an incident happens.

Checking your posture

Checking each of these items manually takes a full day of console work. plainfra can audit your security posture in a single conversation:

> "Run a security review of our AWS account. Check IAM policies for overly broad permissions, unencrypted resources, public-facing databases, CloudTrail configuration, and security group rules."

You get a prioritised list of findings with specific resources, risk levels, and remediation steps. Run it weekly to catch configuration drift before it becomes a compliance gap.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.