Consolidating CNAPP, Code Security, and DAM for an NPCI-Regulated Payments FinTech on AWS

Customer Snapshot

Attribute	Details
Industry	Payments / Financial Technology
Cloud Environment	AWS (28 accounts)
Workloads	EC2 and ECS (production), modernising to EKS
IAM / Identity	Azure AD
Team Size	50–60 developers
Code & CI/CD	Bitbucket (SCM), Jenkins (CI/CD)
Compliance	RBI, NPCI, DPDP
Existing Security	Legacy CNAPP vendor (expiring), DLP (separate vendor), antivirus, no DAM
Primary Interest	Unified platform: CSPM, Code Security (SBOM), DAM, JIT, Workload Security
Coding Agents	Adopted by engineering team; no guardrails in place

The Situation: A Payments FinTech Outgrowing Its Security Stack

This is a payments technology company operating under some of India’s most stringent regulatory frameworks: RBI, NPCI, and the Digital Personal Data Protection Act (DPDP). Their infrastructure spans 28 AWS accounts, running production workloads on EC2 and ECS today, with a planned modernisation to EKS (Kubernetes) on the horizon.

The engineering team of 50–60 developers ships code through Bitbucket and Jenkins pipelines. Their identity is managed through Azure AD. The compliance surface is not theoretical — NPCI mandates govern how payment data flows, who can access transaction databases, and what audit evidence must exist for every privileged operation.

Their existing CNAPP vendor’s subscription was expiring. Rather than renew, the security leadership saw an opportunity to consolidate. The existing stack was fragmented: a CNAPP for cloud posture, a separate DLP tool for data loss prevention, standalone antivirus, and a SIEM for log aggregation. Each tool solved one problem. None of them talked to each other. And critically, two areas had no coverage at all: code security (no SBOM, no secrets scanning, no SAST in the CI/CD pipeline) and database activity monitoring (internal CloudWatch and slow logs were the only visibility into database access).

The goal was not incremental improvement. It was consolidation: replace multiple point solutions with a single platform that covers CNAPP, code security, DAM, JIT access, and workload protection — while satisfying RBI, NPCI, and DPDP compliance requirements without increasing the cost burden passed to their own customers.

The Core Challenge

28 AWS accounts, 50–60 developers, NPCI-regulated payment workloads, an expiring legacy CNAPP contract, no code security pipeline, no database activity monitoring, and a modernisation to Kubernetes in progress — all governed by regulatory frameworks that demand granular audit evidence for every access decision and data operation.

Where the Gaps Were

Gap 1: No Code Security — Zero Visibility Into What Ships to Production

The engineering team uses Bitbucket for source control and Jenkins for CI/CD. Code goes from developer machine → Bitbucket PR → Jenkins build → container deployed to ECS. At no point in this pipeline does a security scan happen.

This means:

• No secrets detection. AWS access keys, database connection strings, API tokens, and payment gateway credentials committed to Bitbucket repositories are invisible to the security team. For a payments company handling transaction data, a leaked credential in source control is a direct path to production payment systems.
• No SAST (Static Application Security Testing). Code-level vulnerabilities — injection flaws, authentication bypasses, insecure deserialization — ship to production undetected until the next penetration test.
• No SCA (Software Composition Analysis). Third-party dependencies with known CVEs are pulled into builds without assessment. A vulnerable library in a payment processing service is a compliance violation waiting to surface.
• No SBOM (Software Bill of Materials). The team cannot answer the basic question: “What software components run inside our production containers?” When a new critical CVE is published (like Log4Shell), the response is manual: search every repository, check every Dockerfile, hope nothing was missed.

The team explicitly identified SBOM as an urgent need — something they could close within the quarter. For NPCI-regulated workloads, knowing exactly what runs in production is not optional. It is an audit requirement.

Gap 2: Database Access Without Monitoring or Controls

The team’s database visibility consists of CloudWatch metrics and slow query logs. This tells them about performance. It tells them nothing about security.

For a payments fintech under NPCI regulation, the gaps are material:

• No query-level audit trail. Who ran what query, on which database, accessing which tables, at what time — none of this is systematically captured. When NPCI auditors ask “who accessed transaction data in the last 90 days and what did they do?”, the team cannot answer without weeks of manual log archaeology.
• No data masking. Developers with database access see all data in plaintext — including PAN (Primary Account Number) data, customer PII, and transaction details that should be masked based on role and need.
• No destructive query prevention. A mistyped DELETE FROM transactions without a WHERE clause has no safety net. CloudWatch will record the performance impact after the fact. It will not prevent it.
• No separation between read and write access. Engineers debugging a production issue get the same database privileges as those running schema migrations. Every connection is full-privilege by default.

The internal process using CloudWatch and slow logs was acknowledged as inadequate. The team needed a proper DAM solution — but with a critical constraint driven by NPCI compliance.

Gap 3: The NPCI Compliance Concern — Vendor Access to Databases

This is the constraint that shaped the entire DAM evaluation. NPCI compliance imposes strict controls on who (and what) can access payment databases. The security leadership raised a specific concern: can they give a third-party vendor any level of access to databases that process NPCI-regulated payment data?

This is not a hypothetical regulatory concern. NPCI’s guidelines require that organisations:

1. Know and document every entity with access to payment systems.
2. Demonstrate that controls are in place to restrict and audit that access.
3. Maintain evidence that access is limited to the minimum necessary for the function.
4. Have a risk assessment and mitigation plan for any third-party integration.

The concern was that adopting a DAM tool from an external vendor would itself create a compliance violation — giving a third party access to regulated databases.

Gap 4: Fragmented Security Stack With No Cross-Domain Correlation

The existing security posture was assembled over time from point solutions:

• Legacy CNAPP for cloud posture management (subscription expiring).
• Separate DLP tool for data loss prevention.
• Standalone antivirus for endpoint protection.
• SIEM for log aggregation and event correlation.

Each tool generates its own findings in its own console with its own severity model. A misconfigured security group in AWS (CNAPP finding) combined with an over-privileged IAM role (identity finding) combined with a leaked credential in Bitbucket (code finding) are three unrelated alerts in three different dashboards. No tool connects them into the attack path they actually represent.

For a team managing 28 AWS accounts under NPCI regulation, this fragmentation is not just an operational inconvenience. It is a compliance risk: auditors expect consolidated evidence of security controls, not screenshots from five different tools stitched together in a spreadsheet.

Gap 5: No Guardrails on AI Coding Agents

The 50–60 developer team has adopted AI coding agents for development acceleration. These agents read local files, access environment variables, and send prompts to external LLM providers. Without guardrails:

• Credentials in context. A developer asks the agent to “fix the database connection” — and the agent reads the .env file containing production database credentials, payment gateway API keys, and AWS access keys. That entire context is sent to an external LLM endpoint.
• No audit trail. The security team has zero visibility into what data leaves developer machines via AI agent prompts.
• NPCI compliance exposure. If payment-related credentials or transaction data patterns are included in prompts sent to external AI services, that constitutes uncontrolled data flow outside the regulated environment.

For a payments fintech, this is not a “nice to have” concern. It is an active data exfiltration vector that happens silently, with no malicious intent required.

The Cloudanix Solution: One Platform Replacing Five Tools

Cloudanix was introduced as a CNAPP+ platform that consolidates cloud posture, code security, database activity monitoring, JIT access, workload protection, and AI agent security into a single platform — replacing the fragmented stack of expiring and inadequate tools.

Addressing the NPCI Database Access Concern: Agentless, Read-Only Architecture

The first question addressed was the most important one: how does Cloudanix connect to databases without violating NPCI compliance?

The answer is architectural:

• Agentless deployment. Cloudanix DAM does not require installing agents on database servers or within the customer’s VPC. The solution deploys as a secure query proxy on the customer’s own ECS infrastructure.
• Read-only access. The DAM layer requires only read-only access to monitor and analyse queries. It does not need write access, admin privileges, or the ability to modify data.
• Data stays in-region. All query logs and audit trails remain in the customer’s own AWS infrastructure. No payment data or query content leaves the regulated environment.
• Documented risk posture. NPCI compliance does not mandate zero third-party integrations. It mandates that organisations know the risk, document it, have controls in place, and can demonstrate the mitigation plan. Read-only, agentless access with customer-controlled audit storage satisfies this requirement.

This is not a theoretical argument. Other NPCI-regulated fintechs already use Cloudanix DAM under the same compliance framework — the integration is documented, the risk assessment is standardised, and the controls are auditable.

Layer 1: Cloud Security Posture Management (CSPM) — 28 Accounts, One Dashboard

Connect all 28 AWS accounts via read-only IAM roles. Agentless. No infrastructure changes. First findings within 30 minutes.

What this replaces and improves:

• Replaces the expiring CNAPP with continuous posture monitoring across all 28 accounts. Not periodic scans — real-time detection of misconfigurations as they occur.
• Cross-account attack path analysis. A misconfigured security group on an ECS service in Account 12, combined with an IAM role in Account 3 that can assume cross-account access, combined with a database credential exposed in Account 7 — visualised as one attack path, not three isolated findings.
• RBI and NPCI compliance mapping. Every finding is mapped to specific regulatory controls. The team can filter the dashboard by “NPCI-relevant findings” or “RBI compliance gaps” and see exactly what needs attention.
• GenAI-powered remediation. Every finding includes copy-paste-ready AWS CLI commands, CloudFormation snippets, and step-by-step fix guidance. For a team managing 28 accounts, this eliminates the research time between “finding identified” and “fix applied.”
• 1,000+ security checks covering IAM, networking, storage, compute, logging, encryption, and ECS-specific configurations.

For a team moving from a legacy CNAPP that was not being renewed, this is not a lateral move. It is a step-up: unified visibility across all 28 accounts with regulatory mapping that the previous tool did not provide.

Layer 2: Code Security for Bitbucket + Jenkins — SBOM, SAST, SCA, and Secrets

Cloudanix Code Security integrates directly with Bitbucket and Jenkins — the exact SCM and CI/CD combination this team uses. No migration required. No workflow disruption.

What it provides:

• SBOM (Software Bill of Materials). The urgent need. Every container deployed to ECS gets a complete inventory of its software components — packages, libraries, dependencies, and their versions. When the next critical CVE drops, the team answers “are we affected?” in seconds, not days. For NPCI compliance, this is the evidence layer that proves the organisation knows what runs in production.
• Secrets Detection. Every Bitbucket PR is scanned for 2,000+ secret patterns: AWS access keys, database connection strings, payment gateway API tokens, private keys, and more. Findings surface as PR annotations before code merges — the credential that would have reached production is caught at review time.
• SAST (Static Application Security Testing). Source code is analysed for vulnerabilities across 30+ languages and frameworks. Injection flaws, authentication bypasses, and insecure patterns are caught in the development workflow, not during the next penetration test.
• SCA (Software Composition Analysis). Third-party dependencies are checked against vulnerability databases (NVD, GHSA, ecosystem advisories). A vulnerable version of a payment processing library is flagged before it ships.
• PR checks and status gates. Jenkins pipelines can enforce security quality gates: fail the build if a critical secret is detected, block merge if a high-severity CVE is introduced. Security becomes a pipeline stage, not an afterthought.

The Bitbucket-specific advantage: Unlike tools that are GitHub-first with Bitbucket as an afterthought, Cloudanix provides full-feature parity across GitHub, GitLab, and Bitbucket. PR comments, full scans, webhook-driven real-time scanning, and repository-level configuration all work identically on Bitbucket.

SBOM for NPCI compliance: When NPCI auditors ask “what third-party components process payment data?”, the answer is a generated SBOM report — not a manual inventory compiled over weeks. The SBOM is produced automatically with every full scan and is always current.

Layer 3: Database Activity Monitoring (DAM) — Query-Level Security for Payment Databases

Cloudanix DAM deploys as a secure query proxy on the customer’s own infrastructure. Engineers connect to databases through Cloudanix using their existing tools (DBeaver, DataGrip, TablePlus, CLI) — but every query passes through the policy engine before reaching the database.

What it enforces:

• Guardrail policies. Configurable rules that block dangerous operations before they execute:

  • DELETE operations blocked on payment transaction tables.
  • DROP and TRUNCATE operations blocked globally.
  • WHERE clause required on all UPDATE and DELETE queries (prevents accidental mass modifications).
  • Tautology detection (blocks WHERE 1=1 patterns that bypass intended restrictions).
  • Result set limits (cap rows returned to prevent bulk data extraction).

• Dynamic data masking. Sensitive fields are masked in real-time based on user role and policy:

  • PAN data: show only last 4 digits.
  • Customer names: fully masked.
  • Email addresses: username portion masked.
  • Phone numbers: show only last 4 digits.
  • Transaction amounts: hashed for non-privileged users.

  Masking is applied post-execution — the original query semantics are preserved, but the user only sees what their role permits.

• SQL-level audit trail. Every query executed during a session is logged with identity attribution: who ran it, when, on which database, what data was accessed, and what policy decisions were applied. This is the forensic evidence NPCI auditors require.

• Keyless database access. Engineers never see or store database credentials. They authenticate through their Azure AD identity, and Cloudanix provisions a time-bound session with scoped permissions. When the session expires, access is automatically revoked. No shared passwords. No credentials in configuration files. No standing privilege.

How this addresses the NPCI vendor-access concern:

The DAM proxy runs on the customer’s own ECS infrastructure. Database credentials are never transmitted to Cloudanix servers. Query logs stay in the customer’s AWS account. Cloudanix provides the policy engine and the audit capability — but no payment data or database content ever leaves the regulated environment. The integration is agentless, read-only from Cloudanix’s perspective, and fully documented for regulatory evidence.

Layer 4: Just-In-Time (JIT) Access — Zero Standing Privilege Across 28 Accounts

With 28 AWS accounts and NPCI compliance requiring granular access evidence, JIT access eliminates standing privileges and replaces them with time-bound, approval-gated sessions.

How it works for this team:

1. Engineer requests access specifying the account, the role level, the resource, and the duration needed.
2. Approval workflow routes to the CTO/CISO (who holds both roles in this organisation) or a designated approver.
3. Access is provisioned for the approved duration only. AWS IAM role assignment with automatic expiry.
4. Session is identity-stamped. Every action during the session is logged with full attribution.
5. Auto-revocation. When time expires, access disappears. No manual cleanup. No forgotten elevated accounts.

Coverage:

• Cloud JIT: Time-bound access to any of the 28 AWS accounts with scoped IAM roles.
• Database JIT: Integrated with DAM — database access is time-bound and audited at the query level.
• Single-task scoping: A single request can grant access to an EC2 instance and the RDS database it connects to, ensuring the entire debugging task can be completed within one approved, time-bound session.

NPCI compliance value: Every access decision — who requested, who approved, what was accessed, when access expired — is systematically captured. When auditors ask “demonstrate that access to payment systems is controlled, time-bound, and audited,” the evidence is a single export, not a manual compilation across IAM policies, CloudTrail logs, and access review spreadsheets.

Layer 5: Workload Security — EC2 Today, EKS Tomorrow

The team runs production on EC2 and ECS today, with EKS modernisation planned. Cloudanix Workload Protection covers both current and future states:

Current state (EC2 + ECS):

• Runtime vulnerability detection on EC2 instances: crypto mining, brute force attempts, suspicious process execution.
• Container image scanning for ECS workloads: vulnerabilities in base images and dependencies identified before deployment.
• ARM-based EC2 support. The team confirmed they use ARM-based instances — Cloudanix supports these fully, unlike some competitors that only cover x86 workloads.

Future state (EKS):

• Kubernetes security posture for EKS clusters: pod security misconfigurations, IRSA assessment, network policy gaps, and RBAC analysis.
• Runtime protection for containerised workloads: behavioural anomaly detection at the pod level.
• Image-to-runtime correlation: A CVE in a container image, combined with the IAM role attached to the EKS pod, combined with the network reachability of that service — contextualised risk, not standalone CVE counts.

The platform grows with the infrastructure. When the modernisation to EKS happens, the security coverage is already there — no additional tooling procurement, no new vendor evaluation, no gap period during migration.

Layer 6: Coding Agent Guard — Securing 50–60 Developers Using AI Agents

Cloudanix Coding Agent Guard is a pre-hook firewall that sits on developer machines between the AI coding agent and the LLM endpoint. Every prompt and every tool call is inspected before anything leaves the device.

What it catches for this team:

• Payment credentials in prompts. When a developer asks the agent to debug a payment gateway integration, and the agent picks up the API key from the environment — Guard blocks or redacts the credential before it reaches the LLM. The prompt continues without the secret.
• Database connection strings. Production database credentials stored in .env files or configuration — intercepted and redacted.
• PII patterns. Customer data visible in local test files or logs — detected via PII scanning (Luhn-validated credit card numbers, phone numbers, email addresses).

Enforcement modes per severity:

• Critical (payment credentials, AWS keys): Block — the prompt does not leave the device.
• High (database credentials, PII): Redact — the sensitive value is replaced with a placeholder, and the prompt continues safely.
• Medium (internal configuration patterns): Warn — the developer sees a notification, the decision is logged.

Policy synced from Cloudanix Console. The security team configures the policy centrally. Every developer’s Guard installation receives updates automatically. No per-machine configuration. No developer cooperation required.

Audit trail to Console. Every decision (block, redact, warn, allow) is logged with timestamp, developer identity, scanner class, and severity — but never the matched value itself. The Console is an audit plane, not a secrets store. The security team can prove to NPCI auditors that no credentials left developer machines via AI tools, with systematic evidence.

Single-command installation:

cloudanix-guard install all

Covers all supported AI coding agents the team uses. Static Go binary — no Python runtime, no dependency conflicts, installs in under a minute per developer machine.

Pricing: The Consolidation Advantage

A key concern for this team was pricing — specifically, because they pass security costs through to their own customers. Every tool in the stack is a line item that impacts their service pricing.

The individual SKU model addresses this directly. Cloudanix does not force a full platform purchase. Each capability (CSPM, Code Security, DAM, JIT, Workload Security, Coding Agent Guard) is priced as an individual SKU. The team can start with Code Security and DAM (their most urgent needs), expand to CSPM and JIT as the legacy CNAPP expires, and add Workload Security as the EKS modernisation progresses.

The consolidation math:

Before (Fragmented Stack)	After (Cloudanix)
Legacy CNAPP vendor (license expiring)	CSPM + Attack Path (one SKU)
Separate DLP tool (annual license)	DAM with data masking (replaces DLP for database layer)
Standalone antivirus	Workload Security with runtime detection
SIEM (log aggregation)	CDR + real-time event correlation
No code security (gap)	Code Security with SBOM
No JIT (gap)	JIT Access
No AI agent security (gap)	Coding Agent Guard
5+ tools, 5+ vendors, 5+ contracts	1 platform, 1 vendor, individual SKUs

The total platform cost is competitive with the combined spend on the fragmented stack — while covering three areas (Code Security, DAM, Coding Agent Guard) that previously had zero coverage.

India data centre availability. Cloudanix operates data centres in India, and the platform is available on the India marketplace. For a payments fintech where data sovereignty is non-negotiable, this eliminates the procurement friction of working with vendors whose nearest presence is Singapore or US-West.

Compliance Evidence: RBI, NPCI, and DPDP in One Platform

The combination of CSPM, Code Security, DAM, JIT, Workload Security, and Coding Agent Guard produces continuous compliance evidence as a byproduct of daily operations — not as a quarterly audit scramble.

RBI Compliance Evidence

RBI Requirement	Evidence Produced
Information security governance	Continuous posture monitoring across 28 accounts with remediation evidence
Access control and privilege management	JIT: every elevation approved, time-bound, auto-revoked, identity-stamped
Vendor risk management	DAM: agentless, read-only, customer-controlled audit logs — documented risk posture
Incident detection and response	CDR: real-time anomaly detection with identity correlation
Technology risk assessment	CSPM: 1,000+ checks with regulatory mapping and attack path analysis

NPCI Compliance Evidence

NPCI Requirement	Evidence Produced
Payment system access controls	JIT + DAM: time-bound, audited access to payment databases and infrastructure
Third-party risk documentation	DAM architecture documentation: agentless, read-only, data stays in-region
Audit trail for database operations	DAM: query-level logging with identity attribution for every database session
Software integrity	Code Security: SBOM for every production container, SCA for dependency vulnerabilities
Change management evidence	Code Security: every PR scanned, findings tracked, security gates enforced

DPDP Compliance Evidence

DPDP Requirement	Evidence Produced
Data protection measures	DAM: dynamic masking of PII/PAN data based on role and need
Purpose limitation	JIT: access granted only for stated purpose, time-bound, with approval record
Security safeguards	CSPM + Workload Security: continuous posture monitoring with remediation
Breach notification readiness	CDR + DAM audit trail: forensic evidence of what was accessed, by whom, when
Data principal rights	DAM + JIT: identity-stamped trail of all personal data access

One export. One platform. Not five tools, five formats, five evidence-compilation exercises.

The Onboarding Experience

Cloudanix onboarding for this team followed the standard agentless pattern:

1. AWS account connection via read-only IAM roles. CloudFormation stack launched in Mumbai region (ap-south-1). All three primary modules toggled on: CSPM, JIT, Workload Security.
2. Compliance framework selection. SEBI and RBI compliance frameworks selected during onboarding — findings are immediately mapped to regulatory controls.
3. Bitbucket integration for code security. Webhook-driven, repository-level scanning configured for all active repositories.
4. DAM proxy deployment on existing ECS infrastructure. No database configuration changes required. Engineers connect through their existing tools via the Cloudanix proxy.

Time to first findings: Under 30 minutes for CSPM. Code security findings surface on the next PR or full scan. DAM policies enforce from the first connected session.

Platform Impact

28 accounts unified in one dashboard | 50–60 developers under code security and AI agent guardrails | 0 standing database privileges via JIT + DAM | 3 regulatory frameworks (RBI, NPCI, DPDP) with continuous evidence | 5+ tools consolidated into 1 platform | SBOM for every production container | Query-level audit for every database session

Why Consolidation Beats Point Solutions for NPCI-Regulated FinTechs

The fundamental argument for consolidation in this context is not just cost or operational simplicity — it is regulatory coherence.

NPCI, RBI, and DPDP auditors do not evaluate security controls in isolation. They evaluate them as a system: “Can you demonstrate that access to payment data is controlled from code to cloud?” That question spans code security (are credentials in source control?), cloud posture (is the infrastructure misconfigured?), access governance (who can reach the database?), database monitoring (what did they do when they got there?), and AI agent security (is data leaking through new channels?).

A fragmented stack answers each sub-question in a different tool, a different format, a different evidence chain. A unified platform answers the entire question in one export, with cross-domain correlation:

• A credential detected in Bitbucket code (Code Security finding) → connected to the database it grants access to (DAM context) → correlated with who has been using that access (JIT audit) → mapped to the NPCI control it violates (Compliance mapping).

That is one finding, one investigation path, one remediation action. Not four alerts in four tools requiring manual correlation.

Running Payments Infrastructure on AWS with NPCI Compliance Requirements?

If your organisation processes payments under RBI and NPCI regulation, runs workloads across multiple AWS accounts, uses Bitbucket and Jenkins for CI/CD, and needs to consolidate a fragmented security stack without creating new compliance exposure — Cloudanix was built for exactly this scenario.

One platform. Individual SKUs. Code security, DAM, CSPM, JIT, workload protection, and AI agent guardrails. Agentless. Data stays in your infrastructure. Evidence for RBI, NPCI, and DPDP auditors generated continuously.

Book a Demo to see how Cloudanix consolidates your security stack while strengthening your NPCI compliance posture.

Related Resources

• The End of Permanent Access: Next-Generation JIT for Granular Database Security
• Unified Cloud Security for RBI-Regulated Data-Sharing Platform on AWS ECS Fargate
• Shift-Left Code Security for CI/CD Pipelines
• From Tool Sprawl to a Single Dashboard: E-Commerce Cloud Security
• Securing AI Coding Agents at Scale for Enterprise Development Teams
• Database Activity Monitoring: Real-Time Data Security Explained
• What is CNAPP?
• How to Implement JIT Access in AWS, Azure & GCP