Making Sense of Data Classification Under SBP Cloud Guidelines

@kawishwaqar|January 27, 2026 (1m ago)353 views

A Practical Framework for Financial Institutions Navigating Cloud Adoption

The Six-Month Impasse

A mid-sized commercial bank spent six months trying to classify their data for cloud migration. The legal team said one thing, IT said another, and the compliance officer could not find clear guidance in SBP's circulars.

The project stalled for six months while three different consultants gave three different answers. "Critical," "material," "sensitive"—the terminology seemed to shift depending on who you asked.

This is not an isolated case. Across Pakistan's financial sector, institutions face a fundamental challenge: SBP's cloud guidelines reference data classification extensively but provide no explicit taxonomy.

Financial institutions are left to interpret "critical" versus "material" data, leading to inconsistent approaches, compliance uncertainty, and delayed cloud adoption.

How do you protect data when the rules do not tell you what you are protecting?

Understanding SBP's Classification References

The State Bank of Pakistan's cloud framework, primarily outlined in [BPRD Circular No. 01 of 2023], makes repeated references to data classification without providing a taxonomy that institutions can apply.

Sources: SBP BPRD Circular 01/2023 Official Document PDF

Circular Terminology Clarification

Important: The circular uses "material workloads" and "non-material workloads" terminology. These terms are applied to workloads (processing activities), not specific data categories.

"Framework on Outsourcing to Cloud Service Providers: sets out minimum requirements for SBP's REs to outsource their material and non-material workloads to CSPs".

Analysis: The framework does not provide explicit definitions for "material workloads" or "non-material workloads." Section B of the circular (DEFINITIONS) exists, but the actual definitions were not accessible in our research.

Workload Classification Framework

The circular establishes different rules for different types of Regulated Entities:

Sources: DataDarbar Analysis Industry Interpretation, ProPakistani News Coverage Secondary Source

This absence of explicit definitions creates cascading challenges throughout the cloud adoption journey. Data classification determines cloud architecture decisions, including where workloads can run and which providers can be selected. It influences the geographic processing requirements that SBP imposes, directly affecting compliance with data sovereignty expectations.

The classification determines CSP selection criteria, as different tiers of data may require different provider capabilities. It shapes audit and monitoring requirements, with higher-classified data demanding more rigorous oversight.

Finally, it impacts incident response timelines, as the sensitivity of affected data influences notification obligations.

Alignment Challenges with Pakistan's Personal Data Protection Bill 2023

This terminological inconsistency becomes particularly complex when viewed alongside Pakistan's Personal Data Protection Bill 2023 PDPB 2023, which uses its own classification scheme.

Important Status Note: PDPB 2023 is currently a DRAFT bill pending with Senate Standing Committee as of January 2026. It has NOT been passed into law or implemented.

Sources:

The Nation Draft Status Report

Senate.gov.pk Bill Record

Chambers Practice Guide Bill Status

PDPB 2023 Terminology

Sources: JDSupra Legal Analysis PDPB Draft, DataDarbar Analysis PDPB Explainer

Breach Notification Requirements

An institution trying to comply with both frameworks must reconcile these different approaches, often without clear guidance on how to map one taxonomy to another.

International Benchmarks: Learning from Global Approaches

Examining how other jurisdictions approach data classification in financial sector cloud adoption provides valuable context for Pakistan's situation. These international frameworks offer proven approaches that address many of the challenges that Pakistani institutions currently face.

Switzerland's Detailed Classification Model

The Swiss Banking Association has developed a comprehensive classification model specifically for cloud adoption in the financial sector.

Sources: Swiss Bankers Association SBA Cloud Guidelines 2025 Official PDF

Actual SBA Classification:

Sources: Lenz Staehelin Analysis SBA 2025 Review

The Swiss model demonstrates the value of explicit taxonomy. By defining categories with clear criteria and corresponding cloud requirements, SBA provides institutions with actionable guidance rather than ambiguous mandates.

Singapore's Technology Risk Guidelines

The Monetary Authority of Singapore has issued comprehensive technology risk guidelines that include data classification considerations for cloud adoption.

Sources: MAS Technology Risk Management Guidelines 2021 Official PDF

They require financial institutions to establish their own data classification frameworks based on risk assessment, but do not mandate a specific number of tiers.

Key Findings:

• Data Classification: MAS TRM Guidelines require data classification but do not prescribe a specific number of tiers. They require regular review cycles for technology risk management, which would include data governance practices.

The guidelines do not explicitly reference Personal Data Protection Act (PDPA) or require integration of data classification frameworks with PDPA. PDPA is a separate law administered by the Personal Data Protection Commission (PDPC). Financial institutions must comply with both frameworks independently.

The guidelines emphasize that third-party selection should consider risk-based factors, which would naturally include data handling capabilities, but do not explicitly mandate linking data classification tiers to CSP selection criteria.

Sources: MAS Data Governance and Management Practices 2024 Supplementary Document

The MAS framework requires regular monitoring and review of technology risks, which would encompass periodic data governance reviews. The approach provides flexibility while maintaining security standards.

European Banking Authority Guidelines

The EBA Guidelines on Outsourcing to Cloud Service Providers address data classification as part of the outsourcing risk assessment process.

Sources: EBA Guidelines on Outsourcing Arrangements 2019 Official Document

Key Findings:

• Service Criticality vs Data Classification: The guidelines require institutions to determine whether a function is "critical or important" versus "non-critical or non-important" using criteria based on MiFID II. The focus is on service criticality assessment, though this is related to data sensitivity. The principle of proportionality is explicitly emphasized throughout guidelines.

Financial institutions need to keep an updated internal register of all their outsourcing arrangements that must distinguish between outsourcing of critical or important functions, and other outsourcings. The guidelines explicitly address concentration risk, particularly for cloud providers.

The EBA approach emphasizes proportionality, with data classification informing but not determining control requirements. The framework requires institutions to consider data sensitivity alongside other factors including service criticality, market presence, and substitutability when determining appropriate controls.

Key Lessons from International Experience

Comparing these three approaches reveals several consistent principles:

1. Explicit Taxonomy: All three frameworks provide specific categories with criteria (Swiss: 3 tiers, EBA: critical/important, MAS: risk-based). Pakistan's institutions would benefit from similar integration between SBP cloud guidelines and the pending PDPB 2023.
2. Regular Review Requirements: Singapore requires regular monitoring and review of technology risks, acknowledging that data classification is not static. Business processes evolve, new data types emerge, and sensitivity of existing data can change. Annual or quarterly review requirements ensure that classification remains accurate over time.
3. Clear Links to Controls: Swiss SBA guidelines clearly map classification tiers to specific cloud requirements (encryption, TOMs, local processing). When institutions know that classification Tier X requires specific control Y, they can make informed decisions about cloud adoption. Ambiguous requirements lead to inconsistent implementation and compliance uncertainty.

The Real-World Impact: Three Detailed Use Cases

Use Case 1: Core Banking System Migration

A private bank with over 500 branches embarked on migrating its core banking system to cloud infrastructure. The classification exercise revealed complexity of applying SBP's framework to a comprehensive banking environment.

Assessment Challenge: Without explicit SBP definitions, the bank's data fell into multiple classification tiers when analyzed systematically. Customer financial data represented the highest sensitivity level, including account balances, transaction records across all channels, and loan portfolio information. Under any reasonable interpretation, this data would qualify as requiring "material workloads" treatment under SBP's framework.

Source: Industry Analysis - This is a generalized example based on common cloud migration challenges in Pakistan's financial sector. No specific case study documentation is available.

Use Case 2: Digital Banking App Backend

A digital-only bank with a mobile banking application faced classification challenges unique to cloud-native architectures. The multi-tenant environment and distributed data flows amplified classification complexity.

Architecture Challenge: The application's data flows crossed multiple boundaries requiring careful classification at each layer. User devices stored authentication data including encrypted credentials and locally-processed biometrics.

This data remained under bank's control but existed on customer-owned devices, creating classification considerations that extended beyond traditional infrastructure boundaries.

The digital bank discovered that data classification in cloud-native environments must account for data transformation and combination. Data that appears non-sensitive in isolation may become sensitive when combined with other data points.

Source: Industry Analysis - This is a generalized example based on common cloud migration challenges in Pakistan's financial sector. No specific case study documentation is available.

Use Case 3: Payment Service Provider

A licensed payment service provider offering wallet and transfer services faced classification challenges at the intersection of financial regulation and data protection.

Regulatory Overlap: The PSP's data taxonomy reflected the layered nature of payment regulation. Transaction records, including full transaction details, sender and receiver information, and timestamp records, represented the highest sensitivity level.

Compliance data, including AML monitoring records, sanctions screening results, and suspicious activity reports, presented classification challenges. This data served regulatory purposes but also contained sensitive information about customers and transactions.

Source: Industry Analysis - This is a generalized example based on common cloud migration challenges in Pakistan's financial sector. No specific case study documentation is available.

Building Organizational Classification Capability

Successful data classification requires more than documentation. Institutions must build ongoing capability that sustains classification accuracy over time. This capability includes people, processes, and technology components.

People Requirements: Clear ownership of classification decisions is essential. Data owners should be designated for each data category, with responsibility for classification and ongoing review.

A classification governance committee provides oversight and resolves disputes. Training programs ensure that all staff understand classification requirements and their role in maintaining classification accuracy.

Process Requirements: Regular review cycles should be triggered by events such as new system deployments, security incidents, or regulatory changes. Classification decisions should be documented with clear rationale.

Escalation paths should exist for classification disputes. Integration with other governance processes ensures that classification remains current.

Technology Requirements: Automated discovery tools that identify data across the organization. Classification labels should be embedded in data management systems.

Access controls should enforce classification-appropriate restrictions. Monitoring should detect classification violations. Reporting should provide visibility into classification status.

Moving Forward: Practical Classification Framework

Given the absence of explicit SBP definitions, institutions must develop their own classification frameworks. The following provides a practical starting point that aligns with SBP's existing terminology while providing the specificity that institutions need.

Tier 1: Material Workloads (Onshore Required)

Definition: Workloads whose compromise, loss, or unauthorized disclosure would cause severe reputational or financial harm, regulatory breach, or operational failure.

Examples:

• Customer financial data such as account balances, transaction records, and loan information
• Authentication and credential data including passwords, tokens, and cryptographic keys
• Compliance and regulatory data such as AML records, KYC information, and SAR reporting
• Payment card data within PCI scope
• Biometric data if collected

SBP Requirements: Must be outsourced to onshore (domestic) CSPs [BPRD Circular 01/2023 Section E].

Control Recommendations:

• Local processing (Pakistan-based cloud infrastructure) strongly preferred
• Encryption at rest and in transit using strong algorithms required
• No third-party access permitted without appropriate contractual safeguards
• Real-time monitoring and alerting should be implemented
• Automated backup with cross-region disaster recovery capability mandatory
• Full audit logging with seven or more years of retention ensures compliance records remain available

Tier 2: Non-Material Workloads (Offshore Permitted)

Definition: Workloads whose compromise, loss, or unauthorized disclosure would cause moderate reputational impact, customer harm, or require regulatory notification.

Examples:

• Customer contact information such as phone numbers, email addresses, and residential addresses
• Transaction metadata without personally identifiable information
• Business operational data and audit logs including access logs, change logs, and security events
• Third-party integration data
• Internal business communications

SBP Requirements: May be outsourced to offshore CSPs for Banks, MFBs, Digital Banks, DFIs, and Designated PSOs/PSPs [BPRD Circular 01/2023 Section E]. EMIs and Non-designated PSOs/PSPs may outsource even material workloads to offshore CSPs.

Control Recommendations:

• Encryption at rest is required, while encryption in transit is expected for external communications
• Third-party access is permitted with appropriate due diligence and SBP approval for material workloads
• Monitoring and alerting should be implemented
• Backup with disaster recovery capability is required
• Log retention of three or more years ensures records remain available for regulatory purposes

Tier 3: Standard Data (Flexible Processing)

Definition: Information whose compromise, loss, or unauthorized disclosure would have minimal operational, financial, or reputational impact.

Examples:

• Internal business communications
• Non-sensitive operational data
• Public marketing materials
• General system performance data

SBP Requirements: All Regulated Entities may outsource non-material workloads to offshore CSPs [BPRD Circular 01/2023 Section E].

Control Recommendations:

• Standard cloud security controls appropriate to data type
• Encryption in transit expected for external communications
• Access controls appropriate to data type must be implemented
• Standard backup practices apply

Practical Implementation: Templates and Checklists

Implementing data classification requires systematic processes and documentation.

Data Classification Matrix

A comprehensive classification matrix documents how different data categories map to classification tiers and corresponding cloud controls.

Classification Decision Tree

Applying the three tiers requires systematic assessment. The decision process begins with determining whether data is personally identifiable. Sensitive personal data such as financial or biometric information qualifies as material workload. Standard personal data such as name or email falls into non-material classification.

Moving Forward: Building Classification Capability

Data classification represents both a compliance requirement and a foundational capability for cloud adoption. While SBP's guidelines leave classification undefined, institutions must nonetheless make classification decisions to proceed with cloud migration.

The three-tier framework provides a practical starting point that aligns with SBP's existing "material" and "non-material workload" terminology. International benchmarks from Switzerland, Singapore, and European Union offer proven approaches that can inform local adaptation.

Implementation requires more than documentation. Institutions must build ongoing capability including regular classification reviews, staff training, and process integration. Classification should become a natural part of data handling rather than a separate compliance exercise.

For institutions currently stalled on cloud migration due to classification uncertainty, the path forward begins with accepting that some interpretation is necessary. Document that interpretation, apply it consistently, and review it regularly. Regulators generally prefer reasonable interpretations consistently applied over paralysis in the face of ambiguity.

The six-month Karachi bank project eventually moved forward after their compliance officer made classification decisions and documented reasoning. The project team noted that once classification framework was established, subsequent decisions became much simpler. The ambiguity that paralyzed initial planning transformed into a foundation for progress.

Key Takeaways

1. SBP Terminology: BPRD Circular 01/2023 uses "material workloads" and "non-material workloads" terminology, not "critical/material/non-material data." No explicit definitions are provided in the circular [Sources: SBP Circular 01/2023].

2. Processing Location: Material workloads for Banks, MFBs, Digital Banks, DFIs, and Designated PSOs/PSPs must use onshore CSPs. Offshore outsourcing requires SBP approval. Non-material workloads may be outsourced offshore without approval [Sources: DataDarbar, ProPakistani].

3. PDPB 2023 Status: The Personal Data Protection Bill 2023 is currently a DRAFT pending with Senate Standing Committee. It is NOT yet enacted or enforced. It defines "personal data," "sensitive personal data," and "critical personal data" and mandates 72-hour breach notification [Sources: The Nation, Senate.gov.pk, JDSupra].

Practical Recommendation:

Institutions should develop internal classification frameworks that align with SBP's workload terminology while mapping to international best practices from Swiss, Singapore, and EBA.

Keywords: SBP Cloud Guidelines, Data Classification, BPRD Circular 01/2023, Cloud Computing, Financial Sector Regulation, Data Sovereignty, Material Workloads, Non-Material Workloads