A global fintech operating at the intersection of traditional finance and digital assets needed a Cloud SOC (Security Operations Center) at bank-grade standards. Devopsity deployed the full AWS security stack, established daily security operations under SLA, and helped the client pass a major US bank's due diligence review.
Industry
Fintech, Digital Assets
Location
United Kingdom / Cayman Islands
Time
01.2025 - Present (ongoing retainer)
Company
Under NDA
The client is a global fintech platform operating at the intersection of traditional finance and digital assets. Their investment portfolio management system handles classical ETFs and securities alongside crypto and NFTs for clients worldwide. The company has approximately 50 employees and is actively pursuing a UK banking license - which means meeting the same strict security, operational, and compliance standards as major financial institutions.
Devopsity was brought in through a partner software house that serves as the client’s development team. Our role is the dedicated cloud infrastructure and security operations partner - effectively the client’s outsourced Cloud SOC (Security Operations Center). This engagement is delivered as part of our security and compliance services.
Devopsity had previously completed a rapid migration of the client’s platform from Heroku to AWS, followed by a post-migration modernisation to ECS. The migration prioritised speed - getting off Heroku before a business deadline. Both projects succeeded, but security was addressed minimally. A few months into production on AWS, an AWS Well-Architected Review exposed a significant backlog of high-risk security items.
Identity and access management was fragmented. AWS access was managed through scattered IAM users with inconsistent MFA enforcement. Some users had long-lived access keys that hadn’t been rotated. There was no centralised identity management, no SSO, and no structured process for granting, reviewing, or revoking access. Credentials for services were handled inconsistently - some in Secrets Manager, others in environment variables or configuration files.
Beyond basic IAM hygiene, the client’s prospectus compliance requirements introduced a more demanding obligation: a full Privileged Access Management solution on the authentication layer with short-lived credentials and session recording. This wasn’t a nice-to-have - it was a regulatory expectation tied to the banking license application.
There was no security monitoring. No Security Hub, no GuardDuty, no Inspector. The client had no centralised view of their security posture, no vulnerability scanning, no threat detection, and no way to know if something was wrong until it became an incident. Security findings from the Well-Architected Review sat in a spreadsheet with no remediation workflow.
The compliance gap was the most pressing business problem. The client was pursuing a UK banking license and needed to pass due diligence reviews from major financial partners. These reviews expected evidence of centralised access management, encryption with customer-managed keys, continuous vulnerability management, incident response procedures, audit logging, long-term data retention, and privileged access controls with session-level auditability. None of these were in place.
A major US bank had already flagged concerns during an initial partnership assessment. Without a demonstrable security operations practice, the client couldn’t advance the banking license application, couldn’t pass partner due diligence, and risked losing the institutional relationships that were critical to their growth.
We replaced the fragmented IAM user setup with AWS IAM Identity Center, deployed at the AWS Organisation management account level. All human access now flows through SSO with MFA enforced for every user. The scattered IAM users from the migration era were decommissioned - no IAM users with console passwords exist.
We went beyond basic SSO deployment. Failed SSO login attempts are monitored through a CloudWatch metric filter that triggers alerts via SNS to Slack, giving the team visibility into potential credential stuffing or brute-force activity against the identity layer.
For the development team (who work through the partner software house), access requests go through Devopsity as the gatekeeper. We evaluate every request against least-privilege principles, grant the appropriate permission set, and document the approval for audit. This access management gatekeeping role is a core part of our security operations SLA.
For service access, every ECS Fargate service runs with a dedicated IAM role pair - task execution role and task role - each scoped to the specific API actions and resource ARNs the service needs. Bastion hosts (EC2) use instance profiles with scoped IAM roles. CI/CD pipelines authenticate via OIDC federation with no long-lived access keys.
All credentials were migrated into AWS Secrets Manager with automatic rotation enabled for database credentials. Hardcoded secrets were eliminated from the codebase entirely. KMS customer-managed keys provide encryption for all data at rest.
To address the prospectus-mandated PAM requirement, we evaluated a series of proprietary PAM solutions through structured proof-of-concept engagements. None of the evaluated products fulfilled the full set of requirements. After this evaluation process, the client decided to build a custom PAM solution tailored to their specific regulatory requirements. Devopsity is actively supporting the development of this solution, providing infrastructure architecture guidance and AWS integration expertise.
We deployed the full AWS-native security stack and established an operational practice around it.
AWS Security Hub is the centralised dashboard. It’s enabled in eu-west-1 with two active standards - AWS Foundational Security Best Practices (FSBP) v1.0.0 and CIS AWS Foundations Benchmark v1.4.0. AutoEnableControls is on, so new controls are picked up automatically. Security Hub aggregates findings from GuardDuty, Inspector, Config, and IAM Access Analyzer into a single prioritised view.
Amazon GuardDuty provides deep threat detection well beyond basic API monitoring. We enabled the full suite of protection types: S3 Protection for detecting anomalous data access patterns, RDS Login Events for monitoring database authentication anomalies, Lambda Network Logs for detecting suspicious outbound connections from serverless functions, and EBS Malware Protection for scanning attached volumes. Runtime Monitoring is enabled with the ECS Fargate agent deployed across all containerised services, providing real-time visibility into process-level activity inside running containers - not just API calls, but what’s actually happening inside the workload. GuardDuty findings at HIGH and MEDIUM severity are routed via EventBridge to SNS to Slack.
Amazon Inspector provides continuous vulnerability scanning across multiple compute types. EC2 instances, ECR container images, Lambda functions, and Lambda code are all scanned. ECR images are scanned automatically on push and re-evaluated when new CVEs are published. Lambda functions are scanned on deployment and rescanned against new vulnerability disclosures.
AWS Config is enabled with continuous recording of all supported resource types, including global IAM resources (roles, users, policies, groups) recorded daily. Config rules are managed by Security Hub - the FSBP and CIS standards activate hundreds of managed rules covering ACM, ALB, CloudTrail, KMS, RDS, S3, IAM, and other services.
The operational practice is what differentiates this from simply enabling services. Devopsity reviews Security Hub daily under a defined SLA. Findings are triaged by severity: critical findings trigger immediate investigation, high findings are remediated within defined timeframes, and medium/low findings are tracked and scheduled.
The result: vulnerability mean time to resolution dropped from 48+ hours to 8 hours - an 83% improvement. Manual security overhead was reduced by 93%.
Network security follows a layered model with all rules defined in Terraform. The ALB is the only component exposed to the internet, with CloudFront serving as the content delivery edge. ECS services only accept traffic from the ALB security group. RDS and OpenSearch only accept connections from ECS service security groups. ElastiCache follows the same pattern. No database or cache is reachable from the internet.
All data is encrypted at rest using KMS customer-managed keys - RDS, OpenSearch, ElastiCache, S3, and EBS volumes. All data in transit uses TLS via ACM-managed certificates. The client controls their encryption keys, which is a specific requirement for financial regulators assessing data sovereignty.
Two multi-region CloudTrail trails are active in production, both with log file validation enabled and CloudWatch Logs integration:
The primary trail (Terraform-managed, eu-west-1) delivers logs to a fully private S3 bucket with writes restricted to the CloudTrail service via a bucket policy with SourceArn conditions - preventing any other principal from writing to or tampering with the audit log. Together the trails capture every API call across all regions.
We implemented a backup strategy with 7-year retention to meet financial industry record-keeping requirements. Recent backups in S3 Standard, transitioning through Infrequent Access to Glacier and eventually Glacier Deep Archive via lifecycle policies. Custom Lambda functions handle cross-region replication for critical data. Disaster recovery procedures are documented in runbooks and tested through annual table-top exercises.
Every security control is defined in Terraform. Security Hub, GuardDuty, Inspector, Config, CloudTrail, IAM Identity Center, IAM roles, security groups, KMS keys, Secrets Manager configurations, backup Lambda functions, and S3 lifecycle policies - all version-controlled, peer-reviewed, and applied through the standard Terraform pipeline. Changes to security infrastructure go through pull request review with specific attention to IAM policy scope and security group rules.
Consistency pays off. Early approaches with passive security monitoring failed to keep SLA and time-to-resolve at an acceptable level. Moving to a structured daily review cadence with clear severity classification was the turning point that brought MTTR down by 83%.
Ready-made PAM solutions for AWS are all opinionated and may not fit your regulatory requirements. Sometimes you need to go for build, not buy - especially when the compliance mandate is specific about session recording granularity and short-lived credential mechanics.
The security hardening phase transitioned into an ongoing Cloud SOC retainer. Devopsity continues to serve as the client’s security operations center - reviewing Security Hub daily under SLA, managing access requests, remediating vulnerabilities, maintaining compliance baselines, and supporting the banking license application. Planned improvements include deploying AWS WAF v2 on the ALB for application-layer protection and enabling Security Hub cross-region aggregation for a unified security view.
AWS Services: Amazon ECS (Fargate), Amazon ECR, Amazon EC2 (bastion hosts), Application Load Balancer, Amazon CloudFront, Amazon RDS, Amazon OpenSearch Service, Amazon ElastiCache, AWS Security Hub, Amazon GuardDuty (with Runtime Monitoring), Amazon Inspector, AWS Config, AWS IAM Identity Center, AWS IAM, AWS Secrets Manager, AWS KMS, Amazon CloudWatch, AWS CloudTrail, AWS Lambda, Amazon SNS, AWS Systems Manager, AWS Chatbot, AWS Budgets, AWS Cost Anomaly Detection, Amazon S3, AWS Certificate Manager, Amazon Route53
Tools: Terraform, GitHub Actions, Docker, aws-vault
Devopsity transformed the client's security posture from a post-migration minimum to a complete Cloud SOC at bank-grade standards. Vulnerability mean time to resolution dropped by 83% (from 48+ hours to 8 hours), manual security overhead was reduced by 93%, the client passed a major US bank's due diligence review, and banking license readiness was achieved.