PII Handling Standard

Organisation: Simpaisa Holdings Document Owner: Daniel O'Reilly, Chief Digital Officer Classification: Confidential Version: 1.0 Date: 3 April 2026 Status: Active Jurisdictions: Pakistan, Bangladesh, Nepal, Iraq, UAE

---

Table of Contents

1. Purpose & Scope
2. Data Classification
3. PII Field Inventory
4. Masking Rules
5. Encryption Standards
6. Log Masking
7. Response Masking
8. Cross-Border Data Flows
9. Retention Periods
10. Right to Deletion
11. Breach Notification
12. Implementation Checklist

---

1. Purpose & Scope

1.1 Purpose

This standard defines how Simpaisa handles personally identifiable information (PII) across all systems, products, and jurisdictions. It exists because:

• Simpaisa processes PII for 270M+ transactions annually across six jurisdictions, each with distinct data protection regimes.
• The current PII handling posture is rated 3/10 (Critical) — PII is stored in plain text, logged without masking, and data flows cross borders without documented controls.
• Payment data is a high-value target. A PII breach at Simpaisa's scale would trigger regulatory action in multiple jurisdictions simultaneously.

1.2 Scope

This standard applies to:

Scope	Coverage
Products	Pay-Ins, Pay-Outs (Disbursements), Remittances, Cards
Systems	All backend services, databases, API gateways, logging infrastructure, monitoring tools, merchant portals, admin interfaces
Data states	At rest, in transit, in use, in logs, in backups, in non-production environments
Jurisdictions	Pakistan (SBP), Bangladesh (Bangladesh Bank), Nepal (NRB), Iraq (CBI), UAE (DIFC/CBUAE)
Personnel	All Simpaisa employees, contractors, and third-party vendors with access to PII

1.3 Regulatory Basis

Jurisdiction	Primary Regulation	Data Protection Law
Pakistan	PS&EFT Act 2007; PSO/PSP Rules 2014	Personal Data Protection Bill (pending — apply SBP requirements)
Bangladesh	Bangladesh Payment and Settlement Systems Regulations 2014; MFS Regulations 2022	Digital Security Act 2018; ICT Security Guideline v4.0 (2023)
Nepal	Payment and Settlement Act 2019 (2075 B.S.)	Individual Privacy Act 2018 (2075 B.S.)
Iraq	CBI Electronic Payment Services Regulation 2024	No comprehensive data protection law; CBI circulars apply
UAE	DIFC Data Protection Law No. 5 of 2020	Federal Decree-Law No. 45 of 2021 on Personal Data Protection

---

2. Data Classification

Data classification follows the framework defined in DATA-ARCHITECTURE.md, Section 5.

Level	Definition	PII Examples	Handling Requirements
Public	Data intended for public disclosure	Product names, bank lists, fee schedules, currency codes, country codes	No restrictions on storage or transmission
Internal	Business data not for external disclosure	Transaction volumes, merchant IDs, operator definitions, status codes, internal error mappings	Access restricted to Simpaisa employees; encrypted in transit
Confidential	Data whose disclosure could cause significant harm	MSISDN, email, names, account numbers, beneficiary details, IBAN, CNIC/NID	Encrypted at rest (AES-256-GCM column-level) and in transit; access logged; masked in non-production
Restricted	Data whose disclosure could cause severe operational or legal harm	Card PAN, CVV, operator API keys, signing keys, encryption keys, AML flags	Encrypted with dedicated keys; access requires MFA; stored in isolated vaults; never logged; PCI DSS controls

2.1 Classification Decision Rules

Rule	Detail
When in doubt, classify higher	If a field's sensitivity is unclear, treat it as Confidential until reviewed
Combination amplifies	Two Internal fields combined may constitute Confidential data (e.g., merchantId + transaction volume reveals commercial information)
Context matters	A mobile number alone is Confidential; a mobile number linked to a transaction amount and merchant is still Confidential but with higher impact if breached
Classification is permanent	Once data enters a classification level, it does not downgrade unless explicitly anonymised

---

3. PII Field Inventory

3.1 Complete PII Field Map

Field	Products	Classification	Current State	Target State	Regulatory Sensitivity
MSISDN (mobile number)	Pay-Ins, Pay-Outs, Remittances	Confidential	Plain text in transaction table	AES-256-GCM column encryption; HMAC-SHA256 blind index for search	SBP, BB, NRB — customer identifier
Account code (AC)	Pay-Ins	Confidential	Plain text in transaction table	AES-256-GCM column encryption	Links to wallet/bank account
Beneficiary name	Pay-Outs, Remittances	Confidential	Plain text in disbursement tables	AES-256-GCM column encryption	AML screening target
Beneficiary bank account	Pay-Outs, Remittances	Confidential	Plain text in disbursement tables	AES-256-GCM column encryption	Financial account data
Beneficiary IBAN	Pay-Outs, Remittances	Confidential	Plain text in disbursement tables	AES-256-GCM column encryption	Financial account data
Beneficiary CNIC/NID	Pay-Outs, Remittances	Confidential	Plain text in disbursement tables	AES-256-GCM column encryption	National identity document
Sender name	Remittances	Confidential	Plain text in remittance tables	AES-256-GCM column encryption	AML screening target; FATF Travel Rule
Sender ID document	Remittances	Confidential	Plain text in remittance tables	AES-256-GCM column encryption	Passport/NID — identity verification
Receiver name	Remittances	Confidential	Plain text in remittance tables	AES-256-GCM column encryption	AML screening target
Receiver MSISDN	Remittances	Confidential	Plain text in remittance tables	AES-256-GCM column encryption	Customer identifier
Receiver bank account	Remittances	Confidential	Plain text in remittance tables	AES-256-GCM column encryption	Financial account data
Email address	All (merchant contact)	Confidential	Plain text in merchant_detail	AES-256-GCM column encryption	Contact PII
Phone number	All (merchant contact)	Confidential	Plain text in merchant_detail	AES-256-GCM column encryption	Contact PII
Contact name	All (merchant contact)	Confidential	Plain text in merchant_detail	AES-256-GCM column encryption	Contact PII
Card PAN	Cards	Restricted	Encrypted (PCI requirement)	Tokenised via processor; PAN never stored by Simpaisa	PCI DSS v4.0.1 scope
Card CVV	Cards	Restricted	Must not be stored	Must not be stored post-authorisation	PCI DSS — storage prohibited
Card expiry	Cards	Restricted	Unknown encryption status	AES-256-GCM column encryption	PCI DSS scope
Cardholder name	Cards	Confidential	Unknown encryption status	AES-256-GCM column encryption	PCI DSS scope
OTP value	Pay-Ins	Restricted	Transient (in-memory/Redis)	Transient only; hashed in storage; never logged	Must never persist in plain text
IP address	All (API logs)	Confidential	Plain text in api_logs	Retained for fraud/security; masked after 90 days	Network identifier
API request/response body	All (API logs)	Confidential	Plain text in api_logs	PII fields redacted before storage	May contain any PII field above
AML review flags	Remittances	Restricted	In remittance tables	AES-256-GCM column encryption	Regulatory sensitive; disclosure could obstruct investigation

---

4. Masking Rules

4.1 Masking Patterns

PII Type	Masking Pattern	Input Example	Masked Output	Visible Digits
MSISDN (Pakistan)	Show first 2 + last 3	03001234567	03XX-XXXX-567	First 2, last 3
MSISDN (Bangladesh)	Show first 2 + last 3	01712345678	01XX-XXXXX-678	First 2, last 3
MSISDN (Nepal)	Show first 2 + last 3	9801234567	98XX-XXX-567	First 2, last 3
MSISDN (Iraq)	Show first 3 + last 3	07701234567	077XX-XXX-567	First 3, last 3
Account number	Show last 4	1234567890123456	XXXX-XXXX-XXXX-3456	Last 4
Card PAN	First 6 + last 4 (PCI DSS)	4111111111111111	411111XXXXXX1111	First 6, last 4
Email	First character + masked + domain	[email protected]	d***@example.com	First char, full domain
Person name	First initial + masked surname	Daniel O'Reilly	D*** O'R***	First initial of each name part
IBAN	Country code + last 4	PK36SCBL0000001123456702	PK**-****-****-****-6702	Country code, last 4
CNIC/NID	Last 4 digits	35201-1234567-1	XXXXX-XXXXXXX-XX71	Last 4
Passport	Last 3 characters	AB1234567	XXXXXX567	Last 3
Card expiry	Fully masked	12/27	XX/XX	None
Bank account	Last 4 digits	00201234567890	XXXXXXXXXX7890	Last 4
IP address	Last octet masked	192.168.1.42	192.168.1.XXX	First 3 octets

4.2 Masking Application Points

Context	What Gets Masked	Implementation
API responses to merchants	MSISDN, bank accounts, names in all responses unless explicitly required for the operation	Response serialiser middleware in KrakenD gateway
API logs (api_logs table)	All PII fields in request and response bodies redacted before storage	Logging middleware — regex-based PII detection + replacement
OpenSearch / log aggregation	All PII fields masked before ingestion	Log pipeline filter (Fluent Bit or Vector)
Merchant dashboard	PII masked by default; reveal on explicit click with audit log entry	Frontend masking component + backend audit endpoint
Internal admin panel	Full PII visible to authorised roles only; all access logged	RBAC with audit trail per access
Non-production environments	All PII replaced with synthetic data	Data anonymisation pipeline on database restore
Error messages / stack traces	PII never included	Error handler sanitisation layer
NSQ event payloads	PII masked in events consumed by non-owning services	Event schema validation middleware
Grafana dashboards	No PII displayed; use anonymised identifiers	Dashboard variable restrictions
Support tickets / Slack	PII must not be pasted into support channels	Policy enforcement; DLP scanning

4.3 When Full PII Is Permitted

Scenario	Justification	Controls
Transaction processing	Service must see full MSISDN/account to process the payment	Encrypted in transit (mTLS); encrypted at rest; access logged
AML/KYC review	Compliance staff need full identity details for screening	RBAC restricted to Compliance role; audit logged; time-limited sessions
Dispute resolution	Customer support needs full details to investigate a complaint	RBAC restricted to Support role; audit logged; access request required
Regulatory reporting	Regulators may request full transaction details	Approval from Compliance Officer; audit logged; secure transmission

---

5. Encryption Standards

5.1 Encryption at Rest

Requirement	Specification
Algorithm	AES-256-GCM (authenticated encryption with associated data)
Scope	All Confidential and Restricted fields (see PII Field Inventory)
Granularity	Column-level encryption — encrypt individual PII columns, not entire tables
Key management	AWS KMS — one Customer Master Key (CMK) per data classification per market
Key rotation	Automatic rotation every 365 days via KMS; data re-encrypted on next write
Key hierarchy	CMK → Data Encryption Key (DEK) → column values. DEK cached in application for 5-minute TTL
Envelope encryption	DEK encrypted by CMK; only encrypted DEK stored alongside data

5.2 Key Management

Current State	Target State
AWS KMS (CMK per market)	AWS KMS (current) — evaluate ControlPlane.com for unified key management
Key rotation undocumented	Automatic annual rotation with KMS; documented rotation schedule
No per-classification keys	Separate CMKs: one for Confidential, one for Restricted, per market

Key inventory (target):

Key	Purpose	Market	Rotation
simpaisa-pk-confidential	Encrypt Confidential PII in Pakistan	PK	Annual
simpaisa-pk-restricted	Encrypt Restricted data in Pakistan	PK	Annual
simpaisa-bd-confidential	Encrypt Confidential PII in Bangladesh	BD	Annual
simpaisa-bd-restricted	Encrypt Restricted data in Bangladesh	BD	Annual
simpaisa-np-confidential	Encrypt Confidential PII in Nepal	NP	Annual
simpaisa-iq-confidential	Encrypt Confidential PII in Iraq	IQ	Annual

5.3 Searchable Encryption — Blind Index

Requirement	Specification
Algorithm	HMAC-SHA256
Purpose	Enable exact-match search on encrypted fields without decrypting all rows
Key fields	MSISDN (primary lookup key for Pay-Ins), beneficiary account (Pay-Outs)
Implementation	Store HMAC-SHA256(index_key, plaintext_value) in a separate _index column
Index key	Distinct from encryption key; stored in KMS; rotated independently
Search flow	Application computes HMAC of search term → query the index column → retrieve and decrypt matching rows
Limitation	Supports exact match only; no partial match, no range queries on encrypted fields

5.4 Encryption in Transit

Requirement	Specification
External API traffic	TLS 1.2 minimum, TLS 1.3 preferred; terminated at Cloudflare edge
Gateway to service	mTLS between KrakenD and backend services
Service to service	mTLS via Caddy sidecar proxies
Service to database	TLS 1.2 minimum; RDS enforces require_secure_transport
Service to Redis	TLS 1.2; ElastiCache in-transit encryption enabled
Cross-region replication	TLS 1.3; encrypted S3 transfers with KMS

---

6. Log Masking

6.1 Absolute Prohibitions

The following data MUST NEVER appear in any log — application logs, API logs, OpenSearch, CloudWatch, Grafana, or any other logging/monitoring system:

Data Type	Reason
Card PAN (full or partial beyond first 6 + last 4)	PCI DSS Requirement 3.4
CVV / CVC / CID	PCI DSS — must never be stored post-authorisation
OTP values	Security — enables replay attacks
Passwords / PINs	Security — enables account takeover
Signing keys / API secrets	Security — enables impersonation
Operator API keys / credentials	Security — enables upstream channel compromise
Full encryption keys / DEKs	Security — enables decryption of all protected data

6.2 Masked in Logs

The following data MUST be masked using the patterns in Section 4 before writing to any log:

Data Type	Masking Pattern in Logs
MSISDN	03XX-XXXX-567
Account numbers	XXXXXX7890
Email addresses	d***@example.com
Person names	D*** O'R***
IBAN	PK**-****-****-****-6702
CNIC/NID	XXXXX-XXXXXXX-XX71
IP addresses	Retained in full for 90 days (security), then last octet masked

6.3 Log Masking Implementation

Layer	Implementation	Tool
Application layer	Structured logging with PII-aware serialiser; PII fields tagged and masked at serialisation time	Go slog with custom handler
API gateway	KrakenD request/response logging with PII field exclusion list	KrakenD logging plugin
Log pipeline	Secondary masking pass for any PII that escapes application-level masking	Fluent Bit or Vector with regex processors
Log storage	Field-level access control in OpenSearch; PII fields restricted to Security and Compliance roles	OpenSearch security plugin (RBAC)

6.4 Log Masking Verification

Check	Frequency	Method
Automated PII scanning	Daily	Regex scan of last 24 hours of logs for unmasked PII patterns (MSISDN, email, card numbers)
Manual audit	Monthly	Security team samples 100 random log entries across all services to verify masking
Penetration test scope	Annually	External pen test includes log review for PII leakage

---

7. Response Masking

7.1 Merchant API Response Rules

Rule	Detail
Default: mask	All PII fields in API responses to merchants are masked by default
Exception: operational need	Full PII is returned only when the merchant explicitly needs it for the operation (e.g., payment confirmation showing last 4 digits of the account)
Never return	CVV, OTP values, full card PAN, signing keys — never included in any API response
Masking at gateway	KrakenD response transformer applies masking before the response leaves the gateway

7.2 Response Masking by Product

Product	Endpoint	Field	Returned As
Pay-Ins	Transaction status	msisdn	03XX-XXXX-567
Pay-Ins	Transaction status	accountCode	XXXXXX7890
Pay-Outs	Disbursement status	beneficiaryName	D*** O'R***
Pay-Outs	Disbursement status	beneficiaryAccount	XXXXXX7890
Pay-Outs	Disbursement status	beneficiaryIban	PK**-****-****-****-6702
Remittances	Remittance status	senderName	D*** O'R***
Remittances	Remittance status	receiverName	D*** O'R***
Remittances	Remittance status	receiverMsisdn	98XX-XXX-567
Cards	Payment status	cardNumber	411111XXXXXX1111
Cards	Payment status	cardholderName	D*** O'R***

---

8. Cross-Border Data Flows

8.1 Data Residency Requirements

Jurisdiction	Requirement	Simpaisa Implementation
Pakistan	SBP requires payment system processing infrastructure to reside within Pakistan. Transaction data must be stored on servers located in Pakistan. PSO/PSP Rules 2014 require maintaining processing systems within Pakistan.	Primary RDS instance in AWS ap-south-1 (Mumbai) — gap: need Pakistan-based infrastructure or formal SBP exemption. All transaction data for PK operations stored in PK-designated database.
Bangladesh	Bangladesh Bank ICT Security Guideline v4.0 (2023) requires financial data to be stored within Bangladesh. MFS Regulations 2022 mandate data localisation for all MFS-related data.	Transaction data for BD operations replicated to BD-designated database. No raw PII crosses to UAE.
Nepal	NRB Payment and Settlement Act 2019 requires PSP infrastructure to be located in Nepal. NRB directives require government-approved data centres only.	Transaction data for NP operations stored in NP-designated infrastructure. Partner-managed infrastructure in Nepal.
Iraq	CBI Electronic Payment Services Regulation 2024 requires records maintained within Iraq for minimum 5 years. CBI requires on-site inspection capability.	Transaction data for IQ operations stored in IQ-designated infrastructure.
UAE (DIFC)	DIFC Data Protection Law No. 5 of 2020 — cross-border transfers permitted to jurisdictions with adequate protection or with appropriate safeguards. No raw PII requirement as Simpaisa Holdings is the holding company, not the operating entity.	Receives aggregated/anonymised reports only. No raw PII stored in UAE.

8.2 Cross-Border Transfer Rules

Transfer Type	Permitted	Conditions
Raw PII: Operating entity → UAE holding	No	Only aggregated/anonymised data; no raw PII crosses to UAE
Raw PII: Pakistan → Bangladesh (remittance)	Yes — operational necessity	Required for remittance processing; full record maintained in both jurisdictions; encrypted in transit (TLS 1.3)
Raw PII: Pakistan → Nepal (remittance)	Yes — operational necessity	Required for remittance processing; full record maintained in both jurisdictions
Raw PII: Any market → third-party vendor	Conditional	Data processing agreement required; vendor must meet Simpaisa security standards; CDO approval required
Aggregated data: Any market → UAE	Yes	Aggregated volumes, revenue, success rates; no individual transaction data
System metrics: Any market → UAE	Yes	Infrastructure metrics only; no transaction-level data; no PII

---

9. Retention Periods

9.1 Retention Schedule

Data Type	Active Retention	Archive Retention	Total	Regulatory Basis
Transaction records	12 months (hot storage)	7 years (cold/S3)	7 years	SBP: 10 years (PS&EFT Act); BB: 5 years; NRB: 5 years; CBI: 5 years; Simpaisa applies strictest
API logs (request/response)	3 months (hot)	9 months (S3 Glacier)	12 months	Operational debugging; PII redacted before storage
Postback/webhook records	6 months (hot)	18 months (S3)	24 months	Merchant dispute resolution window
Refund records	24 months (hot)	5 years (cold)	7 years	Aligned with transaction retention
Audit logs (access, changes)	12 months (hot)	9 years (S3 Glacier)	10 years	SBP: 10 years; regulatory audit trail
Merchant profiles (KYB)	Lifetime of relationship	5 years post-termination	Lifetime + 5 years	KYC/KYB retention requirements across all jurisdictions
AML review records	24 months (hot)	8 years (cold)	10 years	FATF recommendations; SBP AML/CFT guidelines; BB BFIU requirements
PII (standalone)	Duration of active relationship	Anonymised at end of retention period	Per data type	MSISDN retained with transaction; anonymised when transaction archived
Card data (PAN)	Never stored post-authorisation	N/A	0	PCI DSS v4.0.1 — PAN must not be stored
Operator credentials	Lifetime of integration	Securely destroyed on decommission	Immediate deletion	Security — no value in retaining expired credentials
IP addresses	90 days (full)	Masked after 90 days; retained with transaction for 7 years	7 years (masked)	Security/fraud investigation

9.2 Retention by Jurisdiction

Jurisdiction	Transaction Records	AML Records	Audit Trail	Merchant KYB
Pakistan (SBP)	10 years (PS&EFT Regulations)	5 years (AML Act 2010)	5 years	5 years post-termination
Bangladesh (BB)	5 years	5 years (MLPA 2012)	5 years	5 years post-termination
Nepal (NRB)	5 years	5 years	5 years	5 years post-termination
Iraq (CBI)	5 years (CBI Regulation 2024)	5 years	5 years	5 years post-termination
UAE (DFSA/DIFC)	6 years	6 years	6 years	6 years post-termination

Simpaisa policy: Apply the strictest requirement across all jurisdictions. SBP's 10-year transaction retention applies globally as the baseline.

---

10. Right to Deletion

10.1 Deletion Request Process

Step	Action	Owner	Timeline
1	Individual submits deletion request via support or regulatory channel	Individual / Regulator	—
2	Verify identity of requestor (prevent fraudulent deletion requests)	Customer Support	2 business days
3	Assess regulatory holds — check if any data is subject to mandatory retention	Compliance	3 business days
4	If no retention obligation: anonymise PII fields (replace with irreversible tokens)	Data Platform	5 business days
5	If retention obligation applies: inform requestor of the specific obligation and timeline	Compliance	5 business days
6	Confirm deletion/anonymisation to requestor	Customer Support	1 business day
7	Audit log entry recording the deletion request, decision, and execution	Automated	Immediate

10.2 Per-Jurisdiction Deletion Rights

Jurisdiction	Right to Deletion	Constraints
Pakistan	No comprehensive right (pending legislation)	SBP retention obligations override; deletion only after retention period expires
Bangladesh	Limited (Digital Security Act 2018)	BB retention obligations override
Nepal	Individual Privacy Act 2018 (2075 B.S.) — right to request correction/deletion	NRB retention obligations override for transaction data
Iraq	No comprehensive right	CBI retention obligations override
UAE (DIFC)	DIFC Data Protection Law 2020 — right to erasure (Article 24)	Exemptions for legal obligations, regulatory compliance

10.3 What Deletion Means at Simpaisa

Action	Detail
Anonymisation, not deletion	Transaction records cannot be deleted due to regulatory retention requirements. PII fields are anonymised (replaced with irreversible tokens).
Audit trail preserved	The fact that a deletion was performed is itself retained in the audit log.
Backups	Anonymisation applied to active data; backup data expires per backup retention policy (30 days rolling). No special backup modification.
Third parties	If PII was shared with upstream operators, deletion request forwarded to the operator per data processing agreement.

---

11. Breach Notification

11.1 Notification Timelines by Jurisdiction

Jurisdiction	Regulator Notification	Individual Notification	Specific Requirements
Pakistan	As soon as practicable; SBP must be notified immediately	No specific timeline	SBP PSD incident reporting; CERT-PK notification
Bangladesh	Bangladesh Bank: within 24 hours	As directed by BB	BB ICT Security Guideline requires immediate incident reporting; BFIU notification for AML-related breaches
Nepal	NRB: within 24 hours	As directed by NRB	NRB Payment Systems Department notification
Iraq	CBI: within 24 hours	No specific requirement	CBI Electronic Payment Services Regulation 2024
UAE (DIFC)	Commissioner of Data Protection: within 72 hours	Without undue delay where high risk to individuals	DIFC Data Protection Law 2020, Article 41

11.2 Breach Notification Process

Step	Action	Owner	Timeline
1	Breach detected or reported	Security team / Any employee	Immediate
2	Initial assessment — scope, data types affected, jurisdictions impacted	Security team + Compliance	Within 1 hour
3	Contain the breach — isolate affected systems, revoke compromised credentials	Security team	Within 2 hours
4	Notify CDO and General Counsel	Security team	Within 2 hours
5	Notify regulators per jurisdiction timelines (CBI: 24 hours; DIFC: 72 hours; Simpaisa internal SLA: 2 hours)	Compliance + Legal	Per timeline
6	Notify affected individuals if required by jurisdiction	Compliance + Communications	As directed
7	Full investigation and root cause analysis	Security team	Within 72 hours
8	Remediation plan documented and executed	Security team + Engineering	Within 7 days
9	Post-incident report submitted to all relevant regulators	Compliance	Within 30 days

11.3 Breach Severity Classification

Severity	Definition	Example	Notification Required
Critical	Restricted data exposed to unauthorised parties	Card PANs, CVVs, operator API keys exposed	All regulators + affected individuals immediately
High	Confidential PII exposed to unauthorised parties	MSISDN, account numbers, beneficiary details exposed	Regulators per jurisdiction timelines
Medium	Internal data exposed; no PII involved	Transaction volumes, fee configurations exposed	Internal notification; regulator notification if required
Low	Potential exposure identified but no evidence of actual access	Misconfigured access control discovered and corrected	Internal notification; document and remediate

---

12. Implementation Checklist

12.1 Encryption

• AES-256-GCM column-level encryption implemented for all Confidential PII fields
• AWS KMS CMKs provisioned per classification per market
• HMAC-SHA256 blind index implemented for MSISDN lookups
• Key rotation schedule documented and automated (annual via KMS)
• Envelope encryption implemented (CMK → DEK → column values)
• DEK caching implemented with 5-minute TTL
• Backward-compatible migration script encrypts existing plain-text PII in batches

12.2 Masking

• API response masking implemented at KrakenD gateway
• Application log masking implemented in all Go services
• Log pipeline secondary masking configured (Fluent Bit / Vector)
• OpenSearch field-level access control configured for PII fields
• Non-production data anonymisation pipeline operational
• Grafana dashboards verified PII-free
• Automated PII scanning of logs running daily

12.3 Data Residency

• Per-jurisdiction database designation documented
• Cross-border data flow register reviewed and current
• Aggregated-only data flows to UAE confirmed
• Data processing agreements in place with all third-party operators
• Pakistan data localisation compliance assessed (SBP infrastructure requirement)

12.4 Retention

• Automated archival pipeline operational (active → S3)
• Automated deletion pipeline operational (post-retention period)
• Legal hold mechanism implemented and tested
• Retention compliance report generating monthly per jurisdiction

12.5 Breach Response

• Breach notification templates prepared per jurisdiction
• Regulator contact details documented and current
• Breach response drill conducted (at least annually)
• Incident reporting integrated with Incident Response Playbook

---

Cross-References

Document	Relevance
DATA-ARCHITECTURE.md	Section 5: Data Classification; Section 6: PII Inventory; Section 7: Retention; Section 8: Cross-Border
SECURITY-ARCHITECTURE.md	Section 11: Data Protection & PII; Section 6: Cryptographic Standards
API-STANDARDS.md	Section 23: PII Handling & Data Retention
INFRASTRUCTURE-STANDARDS.md	Section 11: Secret Management; Section 13: Compliance Infrastructure
INCIDENT-RESPONSE-PLAYBOOK.md	Breach response procedures
CROSS-BORDER-COMPLIANCE-FRAMEWORK.md	Per-jurisdiction regulatory requirements