From Native Tools to Unified CNAPP: Securing a Multi-Entity RBI-Regulated Data-Sharing Platform on AWS ECS Fargate

Indian data-sharing and verification platforms are scaling at a pace that their security tooling cannot match. Multiple entities, RBI-regulated workloads, millions of daily transactions, and a cloud bill that demands optimisation governed by a patchwork of native AWS tools and a third-party SIEM that together leave critical surfaces unmonitored.

This article examines a pattern we encounter repeatedly: a multi-entity Indian platform running entirely on AWS ECS Fargate, handling consent-based personal data across BFSI, background verification, and AI workloads, relying on CloudTrail, GuardDuty, Security Hub, and a SIEM for security; while real-time misconfiguration detection, privileged access governance, credential leak prevention, and 24x7 monitoring remain gaps. We break down why native tools plateau at scale, what a unified CNAPP+ approach looks like for this architecture, and how security consolidation becomes a cost-reduction lever rather than a cost centre.

The Pattern: Multi-Entity Data Platforms Outgrowing Native Security

Here is what this scenario looks like. An Indian technology company operating a consent-based data-sharing and verification platform. Not one product line, but three! Each with its own AWS account, its own compliance surface, and its own risk profile:

• A BFSI entity: RBI-regulated, processing financial data through Account Aggregation and financial analytics. The highest-spend account, handling sensitive regulated data flows.
• A Background Verification (BGV) entity: B2C at scale, running employment verification and identity checks for enterprise hiring, gig economy onboarding, and staffing. Very high transaction volume.
• An AI entity: A consumer AI product growing rapidly, processing voice data, user preferences, and behavioural signals.

The infrastructure is homogeneous: all workloads run on AWS ECS Fargate; serverless containers, no EC2 instances to manage, no Kubernetes clusters to tune. The team has standardised on CDK pipelines for production deployments. Approximately 50 people have some level of AWS console access across the three entities.

The compliance posture is mature on paper: ISO 27001:2022 certified, SOC 2 Type 2 certified, annual VAPT and CISA/CERT audits completed. The certifications are real. The evidence generation to maintain them? That is where the friction lives.

The security stack? CloudTrail enabled but not actively monitored. GuardDuty connected for ECS Fargate runtime. A third-party SIEM deployed for log aggregation. AWS Security Hub aggregating findings. No PAM tool. No credential leak detection. No real-time misconfiguration monitoring. Manual access management that works because the team is small, but will not scale as the platform grows.

And the overriding priority? Cost. AWS credits have been exhausted. The full billing reality has arrived. Every tool, every service, every CloudWatch log stream is now a line item that needs justification.

Why Native AWS Security Tools Plateau for Multi-Entity Platforms

AWS provides a strong baseline of native security services. For a single-account, single-workload startup, they can be sufficient. For a multi-entity platform with three AWS accounts, 50 users, RBI-regulated data flows, and compliance obligations across multiple frameworks, they hit limits that are architectural, and not just feature gaps.

What Native Tools Do Well

• CloudTrail: Logs every API call across all three accounts. The audit data exists.
• GuardDuty: Provides runtime threat detection for ECS Fargate workloads (network anomalies, container behaviour, DNS queries).
• Security Hub: Aggregates findings from GuardDuty, Inspector, and other AWS services into a single view per account.
• IAM provides the policy engine for access control.

Where They Stop

• No cross-account correlation. Security Hub operates per account. A misconfiguration in the BFSI account, combined with an over-privileged IAM role in the AI account, combined with a runtime anomaly in the BGV account, are three separate findings in three separate dashboards. No unified attack path connects them. The security team context-switches between consoles, mentally stitching together a picture that no single tool provides.

• CloudTrail is a log, not a monitor. CloudTrail captures everything. But capturing and monitoring are different problems. When CloudTrail is “enabled but not actively monitored” (a phrase we hear in nearly every engagement with scaled Indian platforms) the audit data exists for forensics after an incident, but provides zero preventive or detective value in real-time. The team discovers what happened days later, not minutes later.

• No privileged access governance. AWS IAM is a powerful policy engine, but it is not a PAM tool. It cannot enforce time-bound elevation, approval workflows, automatic revocation, or identity-stamped session auditing. When IAM access is “mostly time-bound in practice” because the team is small and disciplined, that is culture as a control, not tooling as a control. It works until it does not. A single mis-configured IAM policy, a forgotten user, or a team that grows from 50 to 150 breaks that assumption.

• No credential leak detection. Developers write code. Code sometimes contains secrets. CDK pipeline configurations, environment variables, and CI/CD plugin credentials are the attack surface that AWS native tools were never designed to scan. GuardDuty does not read your Git repositories. Security Hub does not scan your Jenkins plugin configurations.

Security Hub finding fatigue. Security Hub produces findings based on rule packs (CIS, AWS Foundational Security Best Practices). At scale across three accounts, this generates hundreds of findings. But most of them are without remediation context, priority correlation, or blast radius analysis. The signal-to-noise ratio degrades and teams stop looking.

No cost correlation. The security team and the finance team operate in parallel. A CloudWatch bill of ₹2–2.5 lakh/month is a cost line. Whether that spend produces commensurate security value or whether a unified platform could deliver better visibility at lower cost is a question, native tools cannot answer.

The SIEM Gap

A third-party SIEM solves the log aggregation problem. Logs from multiple sources (CloudTrail, application logs, VPC flow logs) can be centralised and searched. But a SIEM is not a CNAPP. It does not understand cloud resource configuration. It does not map IAM policy relationships. It cannot traverse attack paths. It does not provide posture management, code security, or access governance.

For a multi-entity platform, the SIEM handles reactive investigation. The gap is proactive detection of misconfigurations, identity risks, and exposure paths — before they become incidents to investigate.

Security Gaps That Multi-Entity Data Platforms Cannot Afford

The combination of native tools plus a SIEM leaves specific, material gaps for a platform handling consent-based personal data under RBI regulation:

Gap 1: No Real-Time Cloud Monitoring (Only 8–9 Hour Coverage)

Manual security monitoring that covers business hours only (8–9 hours) means the remaining 15–16 hours per day including nights, weekends, and public holidays are unmonitored. For a platform processing financial transactions 24x7 and handling millions of data shares daily, this is not a staffing decision. It is a risk acceptance.

Attackers do not operate on business hours. Credential stuffing, lateral movement, and data exfiltration overwhelmingly happen outside monitored windows. A platform that processes RBI-regulated data cannot credibly claim “appropriate security measures” under its compliance obligations while operating with 60% of the day unmonitored.

Gap 2: Standing Credentials Without Formal Access Governance

50 people with AWS console access across three entities, managed manually, without formal PAM tooling. IAM access that is “time-bound in practice” but without enforcement means:

• No audit trail of who approved access, when, and for what purpose.
• No automatic revocation when a task completes.
• No visibility into credential age, last-used dates, or accumulated permissions.
• No enforcement mechanism when team discipline lapses.

For ISO 27001:2022 (Control 5.18 — Access Rights) and SOC 2 (CC6.1 / CC6.3), auditors will increasingly ask: “How do you demonstrate that access is reviewed, time-bound, and revoked when no longer needed?” The answer “our team is disciplined about it” does not produce the systematic evidence these frameworks require.

Gap 3: No Credential Leak Detection

CDK pipelines deploying to production, Jenkins plugins managing CI/CD, or environment variables holding database connection strings are the normal operational artifacts of a platform engineering team. They are also the most common source of credential exposure.

Without code security scanning (secrets detection, SAST, SCA), the team has no mechanism to detect:

• AWS access keys committed to source control.
• Database credentials hardcoded in CDK constructs or Jenkins pipeline definitions.
• API keys for third-party services embedded in container environment variables.
• Vulnerable dependencies in container images deployed to ECS Fargate.

A single exposed credential in a code repository or CI/CD configuration provides an attacker with direct access to the AWS account, bypassing every network control and IAM policy.

Gap 4: ECS Fargate Workload Visibility Beyond GuardDuty

GuardDuty provides valuable runtime detection for ECS Fargate: DNS-based threats, network anomalies, container-level behavioural signals. But it operates at the network and runtime layer. It does not provide:

• Container image vulnerability scanning before deployment.
• Workload protection that correlates runtime findings with posture and identity.
• Supply chain visibility into base images, dependencies, and their known vulnerabilities.
• Blast radius analysis: if this container is compromised, what can it reach?

For a platform where all workloads are containerised on ECS Fargate, the container supply chain is the attack surface.

Gap 5: Compliance Evidence as a Quarterly Fire Drill

ISO 27001:2022 certified. SOC 2 Type 2 certified. CISA/CERT audits done annually. These are real achievements. But maintaining them (producing evidence for each audit cycle) should not require weeks of manual log collection, screenshot compilation, and policy-to-control mapping.

When CloudTrail logs exist but are not actively monitored, when access reviews are manual, when credential hygiene is not systematically enforced, the evidence for the next audit becomes a scramble. The platform passed the last audit. The question is whether the continuous-control evidence exists for the next one, and the one after that.

The Security-as-Cost-Saving Argument

For a platform where the overriding priority is cost optimisation, where AWS credits are exhausted, billing has started in full, and CloudWatch alone costs ₹2–2.5 lakh/month; security tooling must justify itself financially, not just in risk reduction.

This is the counter-intuitive reality: a unified security platform can cost less than the native tools it replaces when you factor in the full picture.

The True Cost of “Free” Native Tools

AWS native security services are consumption-priced and at scale across three accounts, the costs compound. CloudWatch alone at ₹2–2.5 lakh/month (after optimisation from ₹4 lakh). Security Hub priced per finding. GuardDuty per volume of events analysed. CloudTrail data events per request. Add the SIEM licensing cost, the operational cost of manual 8–9 hour/day monitoring, and engineering time context-switching between multiple consoles.

How Consolidation Reduces Cost

A unified CNAPP+ platform that replaces Security Hub, supplements GuardDuty with correlated posture and identity context, provides real-time monitoring 24x7 (automated, not manual), and adds code security, JIT access, and compliance evidence generation at a platform fee that is competitive with the combined native tool spend is a net cost reduction.

The savings are threefold:

1. Direct tool cost replacement. Security Hub findings, CloudWatch alarms configured purely for security monitoring, and manual SIEM correlation effort become redundant when a CNAPP provides unified detection, posture, and alerting on a single dashboard.

2. Operational cost reduction. Manual 8–9 hour monitoring by a security team becomes automated 24x7 detection with adaptive alerting. The team shifts from monitoring to remediation — higher-value work, same headcount.

3. Compliance cost reduction. Audit evidence that takes weeks to compile manually (access review records, posture snapshots, incident response logs) becomes a single-click export. The compliance and audit-evidence generation across ISO 27001, SOC 2, and DPDPA frameworks is built into the platform.

For a cost-conscious platform spending ₹80+ lakh/month on AWS infrastructure across three entities, the security spend needs to be justified in the same commercial terms. Consolidation is that justification.

What a CNAPP+ Architecture Looks Like for This Platform

For a multi-entity Indian data-sharing platform on AWS ECS Fargate, here is how each Cloudanix module maps to the identified gaps:

Layer 1: Cloud Security Posture Management (CSPM)

Connect all three AWS accounts via read-only IAM roles. Agentless. No infrastructure changes. 30 minutes to first findings.

What it provides across all three entities simultaneously:

• Real-time misconfiguration detection: Not quarterly scans, not daily batch jobs. Continuous. When an S3 bucket policy changes, when a security group opens a port, when an IAM policy grants excessive permissions; the finding surfaces in minutes, not the next audit cycle.
• Cross-account visibility: The BFSI account, BGV account, and AI account on one dashboard, one asset graph, one priority list. Not three separate Security Hub consoles.
• Attack path analysis: A misconfigured security group on an ECS service → combined with an IAM role that can assume a cross-account role → combined with access to an S3 bucket containing PII. That chain is one finding, not three unrelated alerts in three tools.
• Remediation playbooks: Not just “misconfiguration found” but “here is the exact IAM policy/security group rule/S3 bucket policy to apply, copy-paste-ready.”

This directly replaces Security Hub as the primary posture visibility tool, with the advantage of cross-account correlation, attack path traversal, and actionable remediation which Security Hub does not provide.

Every finding includes severity classification, affected resources, and blast radius context. For a team managing three accounts, the unified priority list eliminates the context-switching between Security Hub consoles and answers “what do I fix first?” in one view.

GenAI-powered remediation playbooks provide copy-paste-ready CLI commands and infrastructure-as-code snippets for every finding — so the engineer fixing the misconfiguration does not need to research the solution separately.

Layer 2: Cloud Detection and Response (CDR) + UEBA

Real-time anomaly detection that works 24x7 (automated, not dependent on manual monitoring during business hours).

• Cloud Detection & Response: Correlating CloudTrail events across all three accounts with threat intelligence, behavioural baselines, and identity context. When someone assumes a role at 2 AM that they have never used before, from an IP that has never been seen; that is an alert, not a log entry waiting to be discovered.
• Cloud UEBA: Per-identity behavioural baselines across the 50 users with AWS access. Anomalous console access patterns, unusual API call sequences, geographic travel anomalies. Each identity gets a composite risk score (0–100) that changes continuously, not at the next quarterly review.
• Threat intelligence: Correlation of CISA KEV, EPSS, ThreatFox, and 30+ feeds correlated against the specific assets in these three AWS accounts. Not generic advisories “this CVE affects your container image running in your BFSI account.”

This closes the “8–9 hours only” monitoring gap. The platform does not sleep. It does not take weekends off. It does not miss the 2 AM credential compromise that a manual monitoring rotation would.

Layer 3: Just-In-Time Access for AWS

Replace informal “time-bound in practice” access with formally enforced Just-In-Time access across all three AWS accounts.

Before: Manual Access Management

• 50 people with various IAM permissions across three accounts.
• No formal approval workflow. Access is granted based on request, often persists indefinitely.
• No systematic evidence of access decisions for auditors.
• No automatic revocation when tasks complete.

After: Zero Standing Privilege with JIT

1. A developer needs console access to the BFSI account to investigate a production issue with the Account Aggregation service.
2. They request it via Slack specifying which account, which role level, and for how long.
3. The designated approver (engineering lead, CISO) approves directly in Slack. The approval is logged.
4. Access is granted for the approved duration only. An AWS IAM role assignment is created with automatic expiry.
5. Every action during the session is identity-stamped and logged.
6. Access auto-revokes. The developer returns to zero standing privilege.

For 50 people across three accounts, this transforms access governance from a culture-based control to a tooling-based control with the evidence trail that ISO 27001:2022 and SOC 2 auditors require.

Every JIT session is fully audited: who requested, who approved, what was accessed during the session, and when access was auto-revoked. This is the evidence that ISO 27001 Control 5.18 and SOC 2 CC6.1 demand.

Layer 4: Code Security for CDK Pipelines and Jenkins

The platform deploys production through CDK pipelines. Jenkins handles CI/CD. This is the credential leak surface that currently has no detection.

Code security provides:

• Secrets detection: Scanning CDK constructs, Jenkins pipeline definitions, environment variable configurations, and source code for AWS access keys, database credentials, API tokens, and 2,000+ secret patterns. The credential that would have been deployed to production is caught at the PR stage.
• SAST (Static Application Security Testing): Identifying code-level vulnerabilities before they reach ECS Fargate containers.
• SCA (Software Composition Analysis): Detecting vulnerable dependencies in container images. For a platform running all workloads on ECS Fargate, every base image, every package, every library is part of the supply chain.
• SBOM (Software Bill of Materials): A complete inventory of what runs inside each container, enabling rapid response when a new CVE is published.

Findings surface as PR annotations before code merges, not after it reaches production. The CDK pipeline that currently handles production deployments gains a security quality gate that blocks credential leaks and vulnerable deployments at the source.

Container image scanning extends this to the deployment layer — identifying vulnerable packages in the images that will run on ECS Fargate, before they reach production.

Layer 5: Workload Protection for ECS Fargate

GuardDuty provides runtime signals for ECS Fargate. Workload Protection (CWPP) adds the layers GuardDuty does not cover:

• Container image scanning: Before images deploy to ECS, vulnerabilities are identified in the build pipeline. The shift-left approach catches issues before they reach runtime.
• Runtime correlation: A vulnerability in a container image, combined with the IAM role attached to that ECS task, combined with the network reachability of that service. Not a standalone CVE, but a contextualised risk.
• Blast radius mapping: If this ECS task is compromised, what can it reach? Which S3 buckets? Which databases? Which cross-account roles? The answer determines whether a vulnerability is critical or noise.

This supplements (not replaces) GuardDuty by adding posture context and supply-chain visibility to GuardDuty’s runtime detection.

Layer 6: Data Classification and PII Discovery

The BFSI entity processes financial data under RBI regulation. The BGV entity processes employment records, identity documents, and personal verification data. The AI entity processes voice data and user behavioural signals. All three entities handle personal data subject to India’s Digital Personal Data Protection Act (DPDPA).

Data classification and PII/PHI discovery provides:

• Automated identification of where personal data resides across S3 buckets, databases, and data stores in all three accounts.
• Classification of data sensitivity levels: Financial data vs. Identity documents vs. Behavioural data.
• Visibility into which services and identities can access classified data.
• The evidence layer for DPDPA compliance: “We know where personal data lives, who can access it, and we can prove it.”

DPDPA: The Compliance Pressure That Native Tools Cannot Address

ISO 27001:2022 and SOC 2 Type 2 certifications demonstrate existing compliance maturity. But India’s Digital Personal Data Protection Act (DPDPA) introduces a new compliance dimension that native AWS tools were not designed to address.

What DPDPA Requires

DPDPA enforcement (with penalties up to INR 250 crore) mandates specific, demonstrable controls over personal data processing:

• Data localisation and sovereignty: Clarity on where personal data is processed and stored.
• Purpose limitation: Access to personal data must be limited to the specific processing purpose consented to.
• Consent management: Demonstrable records of consent, purpose, and data access.
• Breach notification: Within 72 hours, with evidence of what was accessed.
• Data principal rights: Ability to demonstrate what personal data exists, who accessed it, and when.

What Native Tools Cannot Produce

For a consent-based data-sharing platform where the core product is facilitating regulated data flows between financial institutions, employers, and consumers; DPDPA compliance is not a peripheral concern. It is an existential one.

CloudTrail can tell you which API calls were made to S3. It cannot tell you which API calls accessed personal data. Security Hub can tell you a bucket is publicly accessible. It cannot tell you which of your 50 users accessed which personal data records, when, and whether that access was within the consented purpose.

How CNAPP+ Addresses DPDPA

The combination of:

• Data classification (knowing where personal data lives across all three entities)
• Identity governance via JIT (controlling and auditing who accesses personal data, when, and for what purpose)
• Real-time detection (alerting on anomalous access to classified data stores)
• Compliance evidence export (one-click evidence generation mapped to DPDPA requirements)

…provides the systematic, continuous, demonstrable compliance posture that DPDPA demands. Not evidence compiled quarterly for an auditor, but evidence that exists continuously as a byproduct of the platform operating.

The Compliance Evidence Payoff

The combination of CSPM (posture), CDR (detection), JIT (access governance), Code Security (shift-left), and Data Classification (data governance) produces audit evidence as a byproduct of daily operations.

ISO 27001:2022 Evidence

ISO 27001:2022 Control	Evidence Produced
5.18 Access Rights	JIT logs: every elevation requested, approved, time-bound, auto-revoked
8.9 Configuration Management	Continuous posture monitoring: every misconfiguration detected and remediated
8.16 Monitoring Activities	24x7 CDR + UEBA: every anomaly detected, every identity risk-scored
8.28 Secure Coding	Code security: secrets detected, vulnerabilities caught at PR stage

SOC 2 Evidence

SOC 2 Control	Evidence Produced
CC6.1 Logical access restricted	JIT: zero standing privilege, every session approved, time-bound, logged
CC6.3 Access removed when no longer needed	Automatic revocation logs for every JIT session
CC6.6 Security events monitored	CDR + UEBA: 24x7 automated monitoring with identity correlation
CC7.2 Anomalies detected and responded to	Behavioural baselines, anomaly detection, risk scoring

DPDPA Evidence

DPDPA Requirement	Evidence Produced
Data localisation	Complete asset inventory with data classification across all three accounts
Purpose limitation	JIT-governed access: every data access is purpose-stated, time-bound, logged
Breach detection	Real-time CDR + UEBA: anomalous access to classified data surfaces in minutes
Data principal rights	Identity-stamped audit trail: who accessed what personal data, when, why

One export. Not weeks of manual compilation across CloudTrail logs, IAM policy reviews, and Security Hub findings.

The Managed Services Angle

For platforms where the security team is lean and the priority is freeing up engineering time for product development, a managed services partner can operate the CNAPP platform on the customer’s behalf. The platform team retains full visibility and control; the managed services partner handles alert triage, remediation recommendations, and compliance reporting.

This model works particularly well for scaled Indian platforms where the engineering talent is focused on product velocity and does not want to context-switch into security operations. The platform provides the tooling; the partner provides the operational layer.

The Architecture: Before and After

Dimension	Before (Native Tools)	After (CNAPP+)
Monitoring	Manual, 8–9 hours/day	Automated, 24x7
Cross-account visibility	Three separate Security Hub consoles	One dashboard, one graph, three accounts
Access governance	Manual, informal, culture-based	JIT: formal, enforced, evidenced
Credential leak detection	None	2,000+ secret patterns scanned at PR stage
Attack path visibility	None (individual findings only)	Cross-account attack path traversal
Compliance evidence	Quarterly manual compilation	Continuous, one-click export
Cost	CloudWatch (₹2.5L) + Security Hub + GuardDuty + SIEM licensing + manual ops	Single platform fee, consolidated
Remediation	Finding + no context	Finding + blast radius + copy-paste-ready fix
Container security	GuardDuty runtime only	Image scanning + runtime + supply chain + blast radius
Data classification	None	Automated PII discovery across all accounts

Key Takeaways for Indian Data-Sharing Platforms

1. Native tools are a foundation, not a solution. CloudTrail, GuardDuty, and Security Hub provide raw capabilities. They do not provide cross-account correlation, attack path analysis, access governance, credential leak detection, or compliance evidence generation. Continue using them as data sources; add a unified layer that correlates and acts on them.

2. Manual monitoring does not scale past business hours. A platform processing regulated data 24x7 cannot credibly claim security with 8–9 hour manual coverage. Automated detection with identity-stamped alerting is the baseline for any compliance framework worth its certification.

3. “Time-bound in practice” is not a control. Auditors increasingly demand formal, evidenced access governance not cultural discipline. JIT access transforms IAM from a policy engine into a governance engine with approval workflows, automatic revocation, and identity-stamped session logs.

4. Security consolidation is a cost-reduction argument. When native tools (Security Hub + CloudWatch + GuardDuty), a third-party SIEM, and manual operations are added together, the total cost often exceeds a unified CNAPP+ platform that delivers broader coverage. For cost-conscious platforms post-credit-exhaustion, this is the commercial case.

5. DPDPA changes the equation for Indian platforms. ISO 27001 and SOC 2 are table stakes. DPDPA with INR 250 crore penalty exposure and mid-2027 enforcement demands data classification, purpose-limited access, and demonstrable breach detection capabilities that native AWS tools cannot provide out of the box.

6. ECS Fargate simplifies the workload story. When all workloads are containerised, security becomes a supply-chain and configuration problem that includes image scanning, task IAM role governance, network reachability mapping, and runtime correlation. Agentless CNAPP is purpose-built for this architecture.

Running Multi-Entity AWS Infrastructure with Native Tools as Your Only Security Layer?

If your Indian platform is scaling across multiple AWS accounts, running ECS Fargate workloads, handling RBI-regulated or DPDPA-subject personal data, and relying on native tools plus manual operations for security, this is the inflection point where cost and risk converge. The native tools will not get cheaper at scale. The compliance requirements will not get lighter. And the monitoring gaps will not close themselves.

Book a Free Assessment to see your multi-account AWS environment through unified posture, cross-account attack paths, access governance, and compliance evidence. Agentless. 30 minutes. Findings the same day.

Related Resources

• CSPM for ECS-Heavy AWS Workloads and Small Security Teams
• Unified Cloud Security for Multi-Cloud Fintech with EKS Workloads
• How to Implement JIT Access in AWS, Azure & GCP
• PAM for Credential Management, Password Rotation, and More in the Cloud
• What is CNAPP (Cloud Native Application Protection Platform)?
• Shift-Left Code Security for CI/CD Pipelines
• Why Excel Is the Biggest Security Risk in Your User Access Review
• Understanding Privileged Access Management