Month: July 2026

AI Governance and Compliance in Indian Financial Services

Posted on by admin
Indian banks, NBFCs, and insurance companies are deploying AI across credit scoring, fraud detection, customer onboarding, KYC verification, investment advisory, claims processing, and customer service. The pace of adoption has accelerated, driven by competitive pressure and the availability of large language models that can be integrated into existing workflows. However, governance frameworks for AI in financial services have not kept pace with deployment. Most organizations deploying AI models lack formal model risk management frameworks, documented bias testing procedures, explainability standards, or clear accountability structures for AI-driven decisions. This gap creates regulatory, reputational, and operational risk. RBI has signaled increasing attention to AI governance through its digital lending guidelines, which restrict the use of automated decisioning without human oversight. SEBI has addressed algorithmic trading governance. IRDAI is examining the use of AI in insurance underwriting and claims. While comprehensive AI regulation specific to financial services is still evolving in India, the direction is clear – regulators expect governed, explainable, and fair AI. Organizations that build governance frameworks now will be ahead of the regulatory curve rather than scrambling to retrofit governance onto deployed systems.

What an AI Governance Framework Should Include ?
An effective AI governance framework for financial services covers five dimensions. First, model inventory and classification. Maintain a complete inventory of every AI model deployed in production, including the business function it serves, the data it uses, the decisions it influences, and its risk classification. Classify models by risk level – high-risk models that affect lending decisions, fraud determinations, or customer pricing require more rigorous governance than low-risk models used for internal analytics. Second, model development standards. Establish standards for data quality, feature selection, training methodology, testing, validation, and deployment. These standards should address bias testing during development, ensuring that models do not discriminate based on protected characteristics. Document the rationale for model design choices – this documentation becomes essential when regulators or auditors ask why a model works the way it does. Third, model validation and testing. Independent validation of AI models – testing by a team separate from the development team – is a fundamental risk management practice. Validation should cover model accuracy, stability, sensitivity to input changes, and fairness across demographic groups. Fourth, monitoring and drift detection. AI models degrade over time as the data they were trained on becomes less representative of current conditions. Implement monitoring that detects model drift, accuracy degradation, and changes in model behavior. Fifth, explainability and transparency. For decisions that affect customers – credit approvals, insurance underwriting, fraud flags – the organization must be able to explain why the AI made a specific decision. This is both a regulatory expectation and a customer trust issue.

Regulatory Expectations You Should Prepare For
RBI’s digital lending guidelines restrict automated decisioning in lending. Lenders must ensure that borrowers are informed when AI is used in credit decisions, and there must be a mechanism for human review of automated decisions. This principle of human-in-the-loop for consequential decisions is likely to extend to other areas as AI regulation matures. For credit scoring models, RBI’s fair practices code requires that lending decisions be non-discriminatory. AI models used in credit scoring must be tested for bias across protected characteristics including gender, religion, caste, and geographic location. If a model produces disparate outcomes for protected groups, the organization must be able to justify the outcome or modify the model. SEBI’s framework for algorithmic trading includes governance requirements for the algorithms – pre-trade risk controls, real-time monitoring, kill switches, and audit trails. These principles are transferable to other AI applications in capital markets – any AI system that executes financial transactions or provides investment recommendations should have similar governance controls. International frameworks provide additional guidance. The EU AI Act classifies AI systems by risk and imposes governance requirements proportionate to the risk level. While this does not directly apply to Indian financial institutions, global clients and partners may require compliance with these standards. NIST’s AI Risk Management Framework provides a practical governance structure that aligns well with existing risk management practices in financial services.

Practical Steps to Build AI Governance Today
Start with what you have. Conduct an AI inventory across your organization – identify every AI model, algorithm, and automated decision system in production. Many organizations are surprised by the number of AI systems operating outside the awareness of the central risk or technology team. Departmental teams may have deployed models through cloud AI services without formal governance approval. Establish an AI governance committee with representation from risk, compliance, technology, legal, and the business functions that deploy AI. This committee should review and approve high-risk AI deployments, set governance standards, oversee model validation, and respond to AI incidents. Implement model risk management practices aligned with established frameworks. If you already have a model risk management function for traditional quantitative models, extend it to cover AI models. The core principles are the same – independent validation, ongoing monitoring, documentation, and accountability. For organizations new to model risk management, start with the high-risk models that affect customer outcomes and build outward. Build explainability into your AI development process from the start. Choose model architectures that support explainability where possible. For complex models like deep learning, implement post-hoc explainability techniques such as SHAP values or LIME. Document the explainability approach for each model and test that explanations are meaningful and accurate. Create an AI incident response framework. AI failures have unique characteristics – a biased model does not produce a single-point failure like a system crash. Instead, it produces systematically incorrect or unfair outcomes over time. Your incident response framework should include triggers for investigating AI behavior anomalies, procedures for model rollback, communication plans for affected customers, and root cause analysis processes.

Data Quality and Privacy in AI Systems
AI governance is inseparable from data governance. The quality, representativeness, and privacy of the data used to train and operate AI models directly determines the quality and fairness of the model’s outputs. If your training data over-represents certain demographics, your model will perform better for those demographics and worse for others. If your training data contains historical biases – such as lending patterns that reflect past discrimination – your model will perpetuate those biases. Implement data quality checks at every stage of the AI pipeline – data collection, preprocessing, feature engineering, training, and inference. Document the data sources, any transformations applied, and the rationale for feature selection. This documentation is essential for audit and for investigating model behavior issues. DPDP compliance adds specific requirements for AI systems that process personal data. Purpose limitation requires that personal data collected for one purpose is not repurposed for AI training without appropriate consent. Data minimization requires that AI systems use only the personal data necessary for their function. The right to explanation may apply when AI-driven decisions significantly affect data principals. Privacy-enhancing technologies – differential privacy, federated learning, data anonymization – can help reconcile the data needs of AI systems with privacy requirements. Evaluate these techniques for your specific use cases, but be aware that they involve trade-offs with model performance that must be explicitly assessed.
Q: Does RBI regulate AI use in banking?
A: RBI has not issued comprehensive AI regulations, but its digital lending guidelines, fair practices code, and technology risk management frameworks all contain provisions that apply to AI deployments. Specific AI governance expectations are expected to evolve.
 
Q: Do we need to explain AI-driven decisions to customers?
A: Yes, for decisions that materially affect customers. RBI’s digital lending guidelines require disclosure of AI use in credit decisions. DPDP Act’s transparency requirements add further obligations for AI systems processing personal data.
Q: What is model risk management for AI?
A: Model risk management is a governance framework for identifying, assessing, monitoring, and controlling the risks associated with AI models. It includes model inventory, independent validation, ongoing monitoring, and documentation.
QRC helps financial institutions build AI governance frameworks aligned with regulatory expectations. Contact us for an AI risk assessment.

FAQ: Cloud Compliance Questions From Fintech CTOs

Posted on by admin
Architecture and Data Residency Questions
Q1: Which cloud providers can we use for payment processing in India?
Any cloud provider with data center regions in India – AWS (Mumbai and Hyderabad), Azure (Pune, Mumbai, and Jio regions), and Google Cloud (Mumbai and Delhi) all support the RBI data localization requirement. The choice should be based on your technical requirements, compliance support, and the provider’s shared responsibility documentation for PCI DSS and other applicable frameworks.

Q2: Can we use a multi-cloud strategy and still be compliant?
Yes, but it increases compliance complexity. Each cloud provider has a different shared responsibility model, different security service configurations, and different compliance documentation. You need consistent security policies across providers and a unified monitoring approach. For PCI DSS, your scope must include all cloud environments that handle cardholder data, regardless of provider.

Q3: Does serverless computing change our compliance obligations?
Your compliance obligations remain the same – the implementation changes. In serverless architectures, you have less infrastructure to manage but more application-level security to handle. You still need to implement access controls, encryption, logging, and vulnerability management. The challenge is that traditional security tools designed for persistent servers may not work in serverless environments.

Q4: How do we handle disaster recovery across regions while maintaining data localization?
Design your DR architecture within Indian cloud regions. Both AWS and Azure have multiple regions in India that can support cross-region disaster recovery while maintaining data residency. Ensure that replication, failover, and backup processes do not route data through regions outside India, even temporarily.

Security and Access Control Questions
Q5: How do we implement PCI DSS network segmentation in the cloud?
Use cloud-native constructs – separate VPCs for CDE and non-CDE workloads, security groups and network ACLs for granular traffic control, and private subnets for sensitive workloads. The segmentation must be validated through penetration testing, and traffic flow between segments must be documented and monitored.

Q6: Should we use cloud-managed encryption or bring our own keys?
For payment data and other highly sensitive information, use customer-managed keys through your cloud provider’s key management service. This gives you control over key rotation, access policies, and key lifecycle management. Cloud-managed keys are acceptable for less sensitive workloads. PCI DSS requires that you manage the keys used to encrypt cardholder data – this is easier to demonstrate with customer-managed keys.

Q7: How do we handle privileged access management in cloud environments?
Implement role-based access with temporary credentials. Use cloud IAM roles instead of long-lived access keys. Enforce MFA for all administrative console access and CLI access. Implement just-in-time access for production environments – users request elevated access for a specific duration rather than having permanent admin rights. Log and monitor all privileged actions through cloud audit logging.

Q8: What cloud security tools should we implement for compliance?
At minimum: cloud security posture management for configuration compliance, cloud workload protection for runtime security, centralized logging with SIEM integration, encryption key management, identity and access management with MFA, and network traffic monitoring. Choose cloud-native tools where possible for deeper integration, and supplement with third-party tools for multi-cloud consistency.

Audit and Compliance Evidence Questions

Q9: How do we demonstrate cloud compliance during a PCI DSS assessment?
Provide your assessor with three things: the cloud provider’s PCI DSS Attestation of Compliance, your shared responsibility matrix showing which controls are your responsibility, and evidence of your control implementation and operational effectiveness. Evidence includes IAM policies, security group configurations, encryption settings, logging configurations, vulnerability scan results, and access review records.

Q10: Can our PCI DSS assessor audit our cloud provider?
You cannot audit the cloud provider directly. Instead, rely on their third-party compliance reports – PCI DSS AOC, SOC 2 Type II report, and ISO 27001 certificate. These are available through the provider’s compliance portal. Your assessor will review these documents and assess whether the provider’s scope of certification covers the services you use.

Q11: How do we maintain continuous compliance in cloud environments?
Implement infrastructure as code to ensure reproducible, auditable configurations. Use automated compliance checking tools that continuously evaluate your cloud configuration against regulatory requirements. Implement change management processes that include compliance review before deployment. Generate compliance reports automatically rather than manually at audit time.

Q12: What documentation should we maintain for cloud compliance?
Maintain your cloud architecture diagrams showing data flows and security boundaries, your shared responsibility matrix with the cloud provider, IAM role definitions and access control policies, encryption configurations and key management procedures, network security group rules and VPC configurations, logging and monitoring configurations, disaster recovery procedures specific to your cloud architecture, and change management records for cloud infrastructure changes.

Cost and Strategy Questions
Q13: How does cloud compliance affect our total cost of ownership?
Compliance adds cost through security tooling, monitoring infrastructure, compliance automation, and assessment fees specific to cloud environments. However, cloud-native compliance tools are generally more cost-effective than equivalent on-premises solutions. The key cost factor is operational – maintaining compliance in cloud environments requires skilled personnel who understand both cloud architecture and regulatory requirements.

Q14: Should we containerize our payment applications for compliance flexibility?
Containers provide consistency across environments, which helps compliance – the same container image tested in staging runs in production. However, container security adds its own requirements: image scanning, registry security, runtime protection, and orchestrator security. For PCI DSS, your container infrastructure is within scope if it handles cardholder data. The compliance benefit of containers is reproducibility and auditability, not scope reduction.

Q15: How do we evaluate a cloud provider’s compliance posture?
Review their compliance certifications – PCI DSS AOC, SOC 2 Type II, ISO 27001. Examine their shared responsibility documentation for your service model. Evaluate their security services and monitoring capabilities. Check their data residency options and guarantee. Review their incident response and notification procedures. Assess their contractual commitments around security, privacy, and compliance. Do not rely solely on certifications – read the scope of each certification to verify it covers the services you intend to use.

Q: Is cloud more or less secure than on-premises for financial services?
A: Neither inherently. Security depends on implementation. Cloud providers invest heavily in physical and infrastructure security, but the customer is responsible for properly configuring and managing their workloads. Misconfigurations are the primary security risk in cloud environments.
Q: Can we use cloud for SWIFT transactions?
A: SWIFT’s Customer Security Programme applies regardless of hosting model. If you run SWIFT infrastructure in the cloud, you must meet the same CSCF requirements. Check SWIFT’s guidance on cloud hosting for specific implementation requirements.
QRC provides cloud security assessments tailored for financial services compliance. Contact us to evaluate your cloud architecture against PCI DSS, RBI, and SEBI requirements.

RBI Cybersecurity Directions 2026: A Complete Compliance Guide

Posted on by admin
RBI’s approach to cybersecurity regulation has evolved from advisory circulars to mandatory directions. The regulatory landscape for financial institutions now includes multiple interconnected directives covering IT governance, cybersecurity frameworks, cyber resilience, outsourcing, and specific technology risks. For banks, the primary directives include the Cybersecurity Framework for Banks, the Technology Risk Management Guidelines, and the Master Direction on Information Technology Governance. For non-bank payment system operators, the Cyber Resilience and Digital Payment Security Controls directions apply. For payment aggregators and payment gateways, the PA/PG guidelines include specific security requirements. For NBFCs, the Technology Risk Management guidelines and cybersecurity requirements apply based on entity size and risk categorization. The challenge for regulated entities is that these directions were issued at different times, address overlapping concerns, and sometimes use different terminology for similar concepts. Building a unified compliance program requires mapping requirements across multiple directions and identifying the common control framework that satisfies all applicable requirements. This is where many organizations struggle – they build separate compliance programs for each directive instead of an integrated approach.

Governance and Organizational Requirements
RBI expects cybersecurity governance to start at the board level. The board of directors must approve the cybersecurity policy, review cybersecurity risks periodically, and ensure adequate resources for the cybersecurity program. A board-level IT Strategy Committee or equivalent must oversee technology risk management. Below the board, a dedicated cybersecurity function led by a Chief Information Security Officer is required. The CISO must report to the board or a board committee, not just to the CIO or CTO, to ensure independence. This reporting structure is specifically called out in RBI’s directions and is a common finding during inspections. The cybersecurity policy must cover at minimum: cybersecurity governance structure, risk assessment methodology, asset management, access control, network security, application security, data security, security monitoring, incident response, business continuity, vendor management, and security awareness training. This policy must be reviewed and updated at least annually, with board approval for significant changes. RBI also requires a distinct Cyber Crisis Management Plan that outlines the organization’s response to large-scale cyber events. This is different from the incident response plan – it addresses scenarios that could affect business continuity, customer trust, and systemic stability. Regular drills and tabletop exercises to test this plan are expected.

Technical Security Controls RBI Expects
Network security requires defense-in-depth with multiple layers of controls – firewalls, intrusion detection and prevention systems, network segmentation, and encrypted communication channels. Internet-facing systems must be placed in DMZ segments with strict access controls. Internal network segmentation between critical systems like core banking, payment processing, and SWIFT, and general corporate systems is mandatory. Access control must follow the principle of least privilege with role-based access, periodic access reviews, and multi-factor authentication for privileged access and remote access. Privileged access management is a specific focus area – monitor and record all privileged user activities. Application security requires secure software development practices, regular security testing including code review and penetration testing, and patch management processes. For critical applications, RBI expects source code review and comprehensive security testing before deployment and after significant changes. Data security requirements include encryption of sensitive data at rest and in transit, data classification, data leakage prevention, and database activity monitoring. Payment system data must be stored in India per the data localization directive. Endpoint security requires protection across all devices that access the regulated entity’s network – anti-malware, endpoint detection and response, device management, and removable media controls. Mobile device management is specifically relevant for organizations that allow mobile access to banking systems.

Incident Detection, Response, and Reporting
RBI mandates a Security Operations Center capability for continuous monitoring and incident detection. For large banks, a 24×7 SOC is expected. For smaller entities, the monitoring capability must be commensurate with their risk profile, but the expectation for timely incident detection remains. The incident response plan must include clear classification criteria, escalation procedures, containment and eradication steps, evidence preservation, communication procedures, and post-incident review. This plan must be tested through regular drills – RBI inspections verify both the existence and testing of the incident response plan. Incident reporting to RBI and CERT-In must occur within the prescribed timeline. The reporting framework requires notification of cyber incidents including data breaches, system compromises, denial of service attacks, malware infections, and any event that impacts the availability or integrity of critical systems. The report must include the nature of the incident, the systems affected, the estimated impact, the containment actions taken, and the planned remediation. Post-incident, RBI expects a root cause analysis and lessons learned report. This report should identify what failed, what worked, what changes are needed to prevent recurrence, and what improvements will be made to the incident response process. Regular cyber drills and simulation exercises are expected, including participation in industry-wide drills coordinated by CERT-In.

Preparing for RBI Inspection and Audit
RBI inspections assess both the existence and effectiveness of cybersecurity controls. Inspectors review policies, test technical controls, examine incident records, evaluate governance structures, and interview key personnel. The inspection is not a documentation review – it is an operational assessment. Prepare by conducting a self-assessment against each applicable RBI direction. Map every requirement to your implemented control, document the evidence that demonstrates the control’s effectiveness, and identify gaps that need remediation before the inspection. Common inspection findings include: inadequate board-level cybersecurity reporting, CISO reporting to CIO instead of the board, incomplete asset inventory, insufficient network segmentation, gaps in privileged access monitoring, incomplete or untested incident response plans, and inadequate vendor security assessment. Maintain an inspection readiness file that includes your cybersecurity policy and board approval records, risk assessment reports, network architecture diagrams with segmentation details, access control matrices and review records, vulnerability assessment and penetration test reports, incident reports and root cause analyses, business continuity and disaster recovery test results, vendor security assessment records, and security awareness training records with completion metrics. The organizations that navigate RBI inspections successfully treat compliance as continuous operational discipline, not an annual preparation exercise. If your controls are operating effectively every day, the inspection becomes a demonstration rather than a scramble.
Q: Does RBI require a SOC for all regulated entities?
A: RBI expects continuous security monitoring capabilities proportionate to the entity’s risk profile. Large banks need 24×7 SOC. Smaller entities can use managed SOC services but must demonstrate effective monitoring.
Q: What is the RBI incident reporting timeline?
A: Cyber incidents must be reported to RBI and CERT-In within the prescribed timeline, typically within 6 hours of detection. The specific timeline may vary by entity type.
Q: Can a CISO report to the CTO under RBI guidelines?
A: RBI expects the CISO to report to the board or a board committee to ensure independence. Reporting to the CTO or CIO is a common inspection finding.
QRC helps banks, NBFCs, and PSOs achieve and maintain RBI cybersecurity compliance. Contact us for a compliance assessment.

Cloud Security Compliance for Financial Services in India

Posted on by admin
Indian financial institutions face a unique regulatory challenge when adopting cloud. Multiple regulators – RBI, SEBI, IRDAI, PFRDA – have issued guidelines that affect how cloud services can be used, where data can be stored, and what security controls must be implemented. RBI’s outsourcing framework requires banks and payment system operators to ensure that their cloud providers meet specific security, availability, and data localization requirements. The data localization mandate requires that payment system data related to Indian transactions is stored exclusively in India.

This does not prohibit cloud usage, but it does restrict your choice of cloud regions and services. SEBI’s CSCRF includes specific provisions for cloud security, requiring regulated entities to assess cloud provider security through their vendor risk management framework and ensure that the cloud deployment meets the same security standards as an on-premises environment. PCI DSS 4.0.1 is technology-agnostic – it applies equally to cloud and on-premises environments. The shared responsibility model adds complexity because both the cloud provider and the customer have PCI DSS obligations, and the division of responsibility varies by service model. Understanding which controls are your responsibility versus the cloud provider’s is the foundation of cloud compliance in financial services.

The Shared Responsibility Model and What It Means for Compliance
Cloud providers operate on a shared responsibility model where they secure the infrastructure, and you secure your workloads, data, and access. The division depends on the service model. In IaaS, you are responsible for the operating system, applications, data, and network configuration. The provider manages the hypervisor, physical infrastructure, and physical security. In PaaS, the provider additionally manages the operating system and runtime, but you remain responsible for applications and data. In SaaS, you are primarily responsible for access management and data protection. The practical implication for compliance is that migrating to cloud does not transfer your compliance obligations to the provider.

If you process cardholder data in an AWS EC2 instance, you are responsible for hardening the operating system, configuring the firewall, implementing intrusion detection, managing encryption, and maintaining access controls. AWS is responsible for the physical security of the data center, the hypervisor layer, and the availability of the compute service. Many financial institutions misunderstand this model and assume that using a PCI DSS-certified cloud provider makes their deployment PCI DSS compliant. It does not. The provider’s compliance covers their layer of the stack – everything above that is your responsibility. Obtain your cloud provider’s PCI DSS Attestation of Compliance and their shared responsibility matrix. Map each PCI DSS requirement to either the provider’s responsibility, your responsibility, or shared responsibility. This mapping is essential for your own PCI DSS assessment.

Data Localization and Cross-Border Considerations
RBI’s data localization directive requires that the full end-to-end transaction data for payment transactions involving India must be stored in systems located in India. This includes the entire payment transaction chain – from transaction initiation to settlement. If you use cloud infrastructure for payment processing, your compute and storage resources must be deployed in Indian cloud regions. All three major cloud providers – AWS, Azure, and Google Cloud – have regions in India. However, data localization goes beyond just choosing an Indian region. Verify that your data does not transit through non-Indian regions during processing. Some cloud services route traffic through global load balancers or edge nodes that may be located outside India.

Ensure that backup, disaster recovery, and log storage also reside in Indian regions. For DPDP compliance, the cross-border transfer framework is different. DPDP permits transfer to countries not on the restricted list but requires appropriate contractual safeguards. This means your cloud provider contracts must address data residency, processing restrictions, and the right to audit. The practical challenge is implementing these requirements across multi-cloud and hybrid environments. Organizations with workloads spanning multiple clouds and on-premises infrastructure need a consistent data governance framework that tracks where data resides across all environments and enforces location-based policies automatically.

Designing a Compliance-Ready Cloud Architecture
Start with network architecture. Implement network segmentation in the cloud using Virtual Private Clouds, subnets, security groups, and network ACLs. For PCI DSS compliance, the cardholder data environment must be segmented from non-CDE workloads. In cloud environments, this means separate VPCs or virtual networks for the CDE, with tightly controlled traffic flow between segments. Implement centralized logging and monitoring. Cloud environments generate enormous volumes of logs – cloud provider activity logs, operating system logs, application logs, and network flow logs. Centralize these in a SIEM or security analytics platform and build detection rules for common attack patterns.

For PCI DSS Requirement 10, ensure that all access to cardholder data in the cloud is logged with sufficient detail for forensic investigation. Implement identity and access management with the principle of least privilege. Use cloud-native IAM services to enforce granular access controls. Implement MFA for all administrative access. Avoid long-lived access keys – use temporary credentials through role assumption wherever possible. For PCI DSS Requirement 7 and 8, document your access control model and evidence how least privilege is enforced. Implement encryption at rest and in transit for all sensitive data. Use cloud-native encryption services with customer-managed keys for maximum control. For PCI DSS Requirement 3, ensure that primary account numbers are encrypted with keys that you manage, not shared keys managed by the cloud provider. For Requirement 4, enforce TLS 1.2 or higher for all data in transit.

Cloud Security Monitoring and Incident Response
Cloud environments require a different approach to security monitoring compared to traditional on-premises infrastructure. You cannot deploy network taps or inline security appliances in the same way. Instead, leverage cloud-native security services – GuardDuty in AWS, Defender for Cloud in Azure, Security Command Center in Google Cloud – combined with your own SIEM infrastructure. Implement cloud security posture management to continuously assess your cloud configuration against security baselines. Configuration drift is the primary risk in cloud environments – a security group change, an S3 bucket made public, or an IAM policy that is too permissive can create exposure within minutes. Automated compliance checking catches these misconfigurations before attackers do. Your incident response plan must address cloud-specific scenarios. How do you isolate a compromised cloud instance? How do you preserve forensic evidence in an ephemeral compute environment? How do you communicate with your cloud provider during an incident?

For RBI-regulated entities, the incident reporting timeline of 6 hours means your cloud incident response playbook must be practiced and validated through regular drills. Container and serverless workloads add additional complexity. Traditional security monitoring approaches that rely on host-based agents do not work in serverless environments. Implement runtime protection for containers, monitor function invocations in serverless architectures, and ensure that your logging covers the full execution lifecycle of ephemeral workloads.

Q: Can banks in India use public cloud for core banking?
A: Yes, with appropriate regulatory compliance. RBI permits cloud usage but requires data localization, vendor risk management, and security controls equivalent to on-premises deployments.
Q: Does using a PCI DSS-certified cloud provider make us compliant?
A: No. The provider’s certification covers their infrastructure layer. You remain responsible for securing your workloads, data, and access controls within the cloud environment.
Q: Where should we store payment data in the cloud?
A: In Indian cloud regions only. RBI mandates that payment system data for Indian transactions must be stored in India. Ensure that backups, logs, and DR sites also reside in Indian regions.
QRC provides cloud security assessments and compliance for financial services. Contact us to evaluate your cloud security posture.