Security Architecture & Controls

Organisation: Simpaisa Holdings Document Owner: Daniel O'Reilly, Chief Digital Officer Classification: Confidential Version: 1.0 Date: 2 April 2026 Status: Active — derived from Architectural Review findings Overall Security Posture: 4/10 (Critical)

---

Table of Contents

1. Executive Summary
2. Security Principles
3. Authentication Architecture
4. Authorisation Model
5. Transport Security
6. Cryptographic Standards
7. API Security Controls
8. Webhook Security
9. OTP & Authentication Flows
10. Credential & Secret Management
11. Data Protection & PII
12. Infrastructure Security
13. Application Security
14. PCI DSS Scope
15. Incident Response
16. Security Monitoring & Logging
17. Vulnerability Management
18. Third-Party / Vendor Security
19. Compliance Matrix
20. Security Remediation Roadmap
21. Appendix: Security Controls Checklist

---

1. Executive Summary

Business Context

Simpaisa is a payment gateway processing over 270 million transactions worth in excess of $1 billion annually across five markets: Pakistan, Bangladesh, Nepal, Iraq, and Egypt. The platform serves four core product lines — Pay-Ins, Pay-Outs (Disbursements), Remittances, and Cards — each with distinct security characteristics that have evolved independently.

Current Risk Posture

The overall security posture is rated 4 out of 10 (Critical). This rating reflects a platform where security controls exist but are inconsistently applied, undocumented, and in several cases fundamentally insufficient for a regulated payment gateway processing this transaction volume.

Key risk indicators:

Area	Score	Risk Level
Transport Security (TLS)	6/10	Medium
Authentication	4/10	High
Authorisation	5/10	Medium-High
Webhook Security	2/10	Critical
Credential Management	6/10	Medium
Data Protection (PII)	3/10	Critical
Input Validation	4/10	High
Rate Limiting	2/10	Critical
OTP Security	4/10	High
Secret Rotation	2/10	Critical

Critical Findings Summary

1. Pay-Ins has no request signing — any party knowing a merchantId can forge transaction requests against the highest-volume product line.
2. Webhook payloads are unsigned — merchants have no mechanism to verify that callbacks originate from Simpaisa, enabling payment status spoofing.
3. 30-minute OTP window — six times the industry standard of 5 minutes, massively expanding the brute-force attack window.
4. Surge deployment token in source control — a credential committed to deploy.sh that provides infrastructure-level access.
5. No documented rate limiting — the platform is vulnerable to brute-force, credential stuffing, and denial-of-service attacks.
6. Database table names exposed in merchant documentation — providing reconnaissance data that aids SQL injection attacks.

Strategic Direction

The target architecture addresses these gaps through centralised security enforcement via KrakenD API Gateway, ControlPlane.com for identity, Cloudflare for edge protection, and a unified RSA-SHA256 + mTLS authentication model across all product lines.

---

2. Security Principles

The following principles govern all security decisions at Simpaisa. They are specific to a regulated payment platform operating across multiple jurisdictions.

2.1 Principles

#	Principle	Description
SP-1	Defence in Depth	No single control shall be the sole protection for any asset. Every layer (edge, gateway, service, data) must enforce independent security checks.
SP-2	Least Privilege	Every identity (human, service, merchant) receives the minimum permissions required. No broad-scope credentials.
SP-3	Zero Trust	No implicit trust based on network location. All requests are authenticated and authorised regardless of origin. mTLS between all services.
SP-4	Consistent Security Posture	All product lines (Pay-Ins, Pay-Outs, Remittances, Cards) must meet the same baseline security standard. No product shall operate below the minimum threshold.
SP-5	Secure by Default	New services, APIs, and integrations must ship with security controls enabled. Security is not opt-in.
SP-6	Fail Secure	On error, systems deny access rather than grant it. Timeouts result in rejection, not approval.
SP-7	Auditability	Every security-relevant event is logged with sufficient detail for forensic analysis and regulatory compliance. Logs are tamper-evident.
SP-8	Regulatory Compliance	Controls must satisfy the most restrictive applicable regulation across all operating jurisdictions (SBP, Bangladesh Bank, Nepal Rastra Bank, CBI Iraq).
SP-9	Cryptographic Agility	Systems must support algorithm migration without redesign. No hard-coded cryptographic choices.
SP-10	Data Minimisation	Collect, process, and retain only the data required. PII handling follows the strictest applicable data protection regime.

2.2 Current State vs Principles

Principle	Compliance	Notes
SP-1 Defence in Depth	Partial	AWS WAF at edge, but no API Gateway layer for centralised enforcement
SP-2 Least Privilege	Unknown	No documented RBAC model; merchantId validation exists but scope unclear
SP-3 Zero Trust	Non-compliant	Pay-Ins uses session cookies; internal service communication security undocumented
SP-4 Consistent Posture	Non-compliant	Cards is strong; Pay-Ins is fundamentally weak; four different auth models
SP-5 Secure by Default	Non-compliant	New integrations appear to inherit whichever pattern was convenient
SP-6 Fail Secure	Unknown	No documentation of failure-mode behaviour
SP-7 Auditability	Partial	CloudWatch logging exists but no security event correlation or SIEM
SP-8 Regulatory Compliance	Partial	PCI DSS for Cards; other regulatory frameworks not systematically mapped
SP-9 Cryptographic Agility	Partial	RSA-2048 used but algorithm selection appears hard-coded per product
SP-10 Data Minimisation	Non-compliant	PII in logs without masking; no retention policy documented

---

3. Authentication Architecture

3.1 Current State — Per-Product Authentication

Authentication is the most significant divergence across product lines. Each product evolved its own authentication mechanism independently.

Pay-Ins (Score: 2/10 — CRITICAL)

Attribute	Detail
Mechanism	Custom HTTP headers + JSESSIONID session cookie
Headers	merchantId, channel, version
Signing	None
Session Management	Server-side Java session (JSESSIONID)
mTLS	Not implemented

Vulnerabilities: - No request signing means any party that discovers a merchantId can forge transaction requests. - JSESSIONID cookies are vulnerable to session fixation, hijacking, and replay. - Custom headers provide identification only, not authentication — they assert identity without proving it. - This is the highest-volume product line, making it the highest-impact target.

Pay-Outs / Disbursements (Score: 8/10 — STRONG)

Attribute	Detail
Mechanism	RSA 2048-bit digital signature + mTLS
Signing Algorithm	SHA-256 with RSA (PKCS#8)
Signed Payload	Full request body
Certificate	Merchant-specific RSA key pair
mTLS	Enforced — client certificate required

Strengths: Request integrity, non-repudiation, mutual authentication at transport layer. Gaps: Key rotation process undocumented; certificate revocation process unclear.

Remittances (Score: 7/10 — STRONG with issues)

Attribute	Detail
Mechanism	RSA digital signature + custom headers
Signing Algorithm	SHA-256 with RSA
Headers	Includes remitance-signature (note: typo — should be remittance-signature)
mTLS	Not confirmed

Strengths: Cryptographic signing provides integrity and non-repudiation. Gaps: Header typo (remitance vs remittance) creates technical debt; mTLS status unconfirmed; correcting the typo requires a coordinated migration with all integrated merchants.

Cards (Score: 9/10 — STRONGEST)

Attribute	Detail
Mechanism	RSA digital signature + mTLS + AES field-level encryption
Signing Algorithm	SHA-256 with RSA (PKCS#8)
Field Encryption	AES for PAN, CVV, expiry (PCI DSS requirement)
mTLS	Enforced
PCI DSS	Compliant

Strengths: Multi-layered security appropriate for cardholder data; meets PCI DSS requirements. Gaps: AES mode (CBC/GCM) not documented; IV generation strategy not documented.

3.2 Authentication Comparison Matrix

Control	Pay-Ins	Pay-Outs	Remittances	Cards
Request signing	No	RSA-SHA256	RSA-SHA256	RSA-SHA256
mTLS	No	Yes	Unconfirmed	Yes
Field encryption	No	No	No	AES
Session-based	Yes (JSESSIONID)	No	No	No
Non-repudiation	No	Yes	Yes	Yes
Replay protection	None documented	None documented	None documented	None documented

3.3 Gaps

ID	Gap	Severity	Product(s)
AUTH-G1	Pay-Ins has zero request signing	Critical	Pay-Ins
AUTH-G2	No replay protection (nonce/timestamp) on any product	High	All
AUTH-G3	JSESSIONID session management on Pay-Ins	Critical	Pay-Ins
AUTH-G4	Key rotation process undocumented	High	Pay-Outs, Remittances, Cards
AUTH-G5	Certificate revocation process undefined	High	Pay-Outs, Cards
AUTH-G6	Header typo remitance-signature	Low	Remittances
AUTH-G7	No centralised authentication enforcement point	High	All

3.4 Target State — Unified Authentication

All product lines shall converge on a single authentication model enforced at the API Gateway (KrakenD).

Target Authentication Stack:

Merchant Request
    │
    ├── Cloudflare Edge (DDoS, bot detection, geo-fencing)
    │
    ├── KrakenD API Gateway
    │       ├── mTLS termination (verify client certificate)
    │       ├── RSA-SHA256 signature verification
    │       ├── Timestamp validation (±5 min clock skew)
    │       ├── Nonce/idempotency key deduplication
    │       └── Rate limiting per merchantId
    │
    ├── ControlPlane.com (identity, RBAC, API key management)
    │
    └── Backend Service (Caddy sidecar for inter-service mTLS)

Target Authentication Requirements (all products):

Requirement	Specification
Request signing	RSA-SHA256 (PKCS#8, 2048-bit minimum, 4096-bit recommended)
Transport	mTLS required for all merchant-facing endpoints
Replay protection	Timestamp header (reject if > 300 seconds old) + unique nonce per request
Session management	Stateless — no server-side sessions; signed request per call
Centralised enforcement	KrakenD API Gateway validates all authentication before routing
Identity provider	ControlPlane.com for merchant identity and API key lifecycle

Priority: P0 — Pay-Ins authentication upgrade is the single highest-priority security remediation.

---

4. Authorisation Model

4.1 Current State (Score: 5/10)

Control	Status	Detail
merchantId validation	Implemented	Requests validated against the authenticated merchant's identity
IDOR prevention	Unknown	No documented testing for insecure direct object reference vulnerabilities
RBAC	Not implemented	No role-based access control; merchant is a flat identity
Scope limitation	Partial	Merchants appear restricted to their own transactions but enforcement mechanism undocumented
Admin access control	Unknown	Internal admin panel authorisation model not documented
API key scoping	Not implemented	No per-key permission scoping (e.g., read-only vs read-write)

4.2 Gaps

ID	Gap	Severity
AUTHZ-G1	No IDOR testing documented — merchants may access other merchants' resources	High
AUTHZ-G2	No RBAC model — all merchant users have identical permissions	Medium
AUTHZ-G3	No API key scoping — keys grant full access to all operations	Medium
AUTHZ-G4	Admin access controls undocumented	High
AUTHZ-G5	No IP whitelisting capability for merchant API access	Medium

4.3 Target State

Authorisation Architecture (via ControlPlane.com):

Layer	Control	Description
Gateway	Merchant identity	KrakenD validates the merchant identity from mTLS certificate + API key
Gateway	Rate/scope enforcement	Per-merchant, per-endpoint rate limits and allowed operations
Service	Resource ownership	Every data access query includes WHERE merchantId = :authenticated_merchant_id
Service	RBAC	Role-based permissions: admin, operator, read-only, webhook-only
Service	IDOR prevention	All resource references validated against the authenticated merchant's scope
Admin	Privileged access	Separate authentication flow; MFA required; session duration limited to 30 minutes

Target RBAC Roles:

Role	Permissions
merchant:admin	Full CRUD on merchant configuration, keys, webhooks; view transactions
merchant:operator	Initiate transactions, view status, manage webhooks
merchant:read-only	View transaction status and reports only
merchant:webhook-only	Receive webhook callbacks only (machine identity)
simpaisa:admin	Platform administration, merchant onboarding, configuration
simpaisa:support	Read-only access to merchant transactions for support purposes
simpaisa:ops	Infrastructure and deployment operations

Priority: P1

---

5. Transport Security

5.1 Current State (Score: 6/10)

Control	Pay-Ins	Pay-Outs	Remittances	Cards
TLS enforced	Yes	Yes	Yes	Yes
TLS version	Undocumented	Undocumented	Undocumented	TLS 1.2+ (PCI DSS)
mTLS	No	Yes	Unconfirmed	Yes
Certificate authority	N/A	Undocumented	Undocumented	Undocumented
Certificate pinning	No	No	No	No
HSTS	Unknown	Unknown	Unknown	Unknown

5.2 Gaps

ID	Gap	Severity
TLS-G1	TLS version not documented or enforced for Pay-Ins	High
TLS-G2	No mTLS on Pay-Ins — transport-layer authentication absent	Critical
TLS-G3	TLS cipher suites not documented or restricted	Medium
TLS-G4	No certificate lifecycle management process	High
TLS-G5	HSTS not confirmed on any endpoint	Medium
TLS-G6	No certificate pinning consideration for mobile SDK integrations	Low

5.3 Target State

TLS Requirements:

Requirement	Specification
Minimum TLS version	TLS 1.2 (TLS 1.3 preferred)
Prohibited protocols	SSLv2, SSLv3, TLS 1.0, TLS 1.1
Cipher suites	AEAD ciphers only: AES-256-GCM, ChaCha20-Poly1305
Key exchange	ECDHE only (no RSA key exchange)
Certificate key size	RSA 2048-bit minimum; ECDSA P-256 or P-384 preferred
Certificate lifetime	90 days maximum (automated renewal via Caddy / Let's Encrypt or Cloudflare)
mTLS	Required on all merchant-facing and inter-service communication
HSTS	Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
OCSP stapling	Required

Certificate Management (Target):

Component	Approach
Edge certificates	Cloudflare-managed, automatic renewal
Service certificates	Caddy auto-TLS with ACME or internal CA
Merchant mTLS certificates	Issued via internal CA; managed through ControlPlane.com
Certificate revocation	CRL and OCSP; automated revocation on merchant offboarding
Certificate monitoring	Automated expiry alerting at 30, 14, and 7 days

Priority: P0 (mTLS for Pay-Ins), P1 (TLS hardening, certificate lifecycle)

---

6. Cryptographic Standards

6.1 Current Cryptographic Usage

Algorithm	Usage	Product(s)	Status
RSA 2048-bit (PKCS#8)	Request signing	Pay-Outs, Remittances, Cards	Active
SHA-256	Signature hash	Pay-Outs, Remittances, Cards	Active
AES (mode undocumented)	Field-level encryption of card data	Cards	Active
None	Request authentication	Pay-Ins	CRITICAL GAP

6.2 Gaps

ID	Gap	Severity
CRYPTO-G1	AES mode not documented (CBC vs GCM) — CBC without proper IV is vulnerable to padding oracle	High
CRYPTO-G2	IV/nonce generation strategy undocumented	High
CRYPTO-G3	Key lengths for AES not documented (128/192/256)	Medium
CRYPTO-G4	No key rotation schedule for RSA or AES keys	High
CRYPTO-G5	No cryptographic algorithm deprecation timeline	Medium
CRYPTO-G6	PKCS#1 v1.5 vs PSS padding not specified — PKCS#1 v1.5 has known vulnerabilities	Medium

6.3 Target Cryptographic Standards

Approved Algorithms:

Purpose	Algorithm	Key Size	Notes
Request signing	RSA with SHA-256	2048-bit minimum, 4096-bit recommended	PKCS#8 format; PSS padding preferred
Field encryption	AES-256-GCM	256-bit	Authenticated encryption; 96-bit random IV per operation
Key exchange	ECDHE	P-256 or P-384	Forward secrecy
Hashing (non-crypto)	SHA-256	N/A	For checksums, idempotency keys
HMAC (webhooks)	HMAC-SHA256	256-bit secret	For webhook signature verification
Password hashing	Argon2id	N/A	For any user-facing password storage
Token generation	CSPRNG	256-bit minimum entropy	For OTPs, API keys, session tokens

Prohibited Algorithms:

Algorithm	Reason
MD5	Collision vulnerabilities
SHA-1	Collision attacks demonstrated
DES / 3DES	Insufficient key length
RC4	Multiple known vulnerabilities
RSA PKCS#1 v1.5 (for encryption)	Bleichenbacher/padding oracle attacks
AES-CBC without HMAC	Padding oracle attacks
AES-ECB	Deterministic; leaks patterns

Key Management Requirements:

Requirement	Specification
RSA key rotation	Every 12 months or on compromise
AES key rotation	Every 6 months or on compromise
HMAC secret rotation	Every 12 months; support dual-secret validation during rollover
Key storage	AWS KMS for master keys; derived keys in Parameter Store
Key generation	HSM-backed or CSPRNG; never application-generated
Key destruction	Cryptographic erasure; documented destruction process

Cryptographic Operations in Rust:

The target architecture specifies Rust for all cryptographic operations to eliminate memory safety vulnerabilities (buffer overflows, use-after-free) in security-critical code paths. Libraries: ring or rustls for TLS, rsa crate for signing.

Priority: P1

---

7. API Security Controls

7.1 Current State

Control	Status	Score
Rate limiting	Mentioned but zero documentation of actual limits	2/10
Input validation	No field-level validation rules documented	4/10
Idempotency	Not documented	Unknown
Error handling	Database table names visible in merchant docs	3/10
Request size limits	Not documented	Unknown
Content-Type enforcement	Not documented	Unknown
CORS	Not documented	Unknown

7.2 Gaps

ID	Gap	Severity
API-G1	No documented rate limits — DoS and brute-force vulnerability	Critical
API-G2	Database table names in merchant documentation — information leakage aiding SQL injection	High
API-G3	No field-level input validation rules documented	High
API-G4	No idempotency mechanism documented — risk of duplicate payments	High
API-G5	Error response content not standardised — potential information leakage	Medium
API-G6	Request payload size limits not documented	Medium

7.3 Target State

Rate Limiting (enforced at KrakenD + Cloudflare):

Endpoint Category	Rate Limit	Window	Action on Exceed
Transaction initiation	100 requests	Per minute per merchantId	429 + exponential backoff
Transaction status query	300 requests	Per minute per merchantId	429
OTP request	3 requests	Per 5 minutes per mobile number	429 + temporary block
OTP verification	5 attempts	Per OTP per session	Lock OTP + 429
Webhook registration	10 requests	Per hour per merchantId	429
Authentication failures	5 attempts	Per 15 minutes per IP	Temporary IP block
Global per-IP	1,000 requests	Per minute	429 + Cloudflare challenge

Input Validation Standards:

Field Type	Validation Rule
merchantId	UUID v4 format; must match authenticated identity
amount	Positive decimal; max 2 decimal places; currency-specific max
currency	ISO 4217 three-letter code; must be in merchant's allowed currencies
mobile/MSISDN	E.164 format; country-specific length validation
email	RFC 5322; max 254 characters
callback URL	HTTPS only; registered domain whitelist per merchant
PAN	Luhn check; BIN validation; 13-19 digits
CVV	3-4 digits only
free-text fields	Max length enforced; HTML/script tag stripped; UTF-8 validated

Idempotency:

Requirement	Specification
Idempotency key	Required header Idempotency-Key on all state-changing requests
Key format	UUID v4 or merchant-generated unique string (max 128 chars)
Deduplication window	24 hours
Behaviour on duplicate	Return original response with X-Idempotent-Replayed: true header
Storage	Redis/DynamoDB with TTL

Error Handling — No Information Leakage:

Rule	Detail
No stack traces	Never expose stack traces, class names, or framework versions
No database details	Never expose table names, column names, or query fragments
Standardised error codes	Use Simpaisa-specific error codes mapped to generic messages
Correlation ID	Every error response includes a X-Request-Id for internal debugging
HTTP status codes	Use correct HTTP semantics (400, 401, 403, 404, 422, 429, 500, 503)

Immediate action: Remove database table names from all merchant-facing documentation.

Priority: P0 (rate limiting, info leakage), P1 (input validation, idempotency)

---

8. Webhook Security

8.1 Current State (Score: 2/10 — CRITICAL)

Control	Status
Webhook delivery	Active — callbacks sent to merchant URLs
Payload signing	Not implemented
Replay protection	Not implemented
IP whitelisting	Not documented
HTTPS enforcement	Not documented
Retry logic	Not documented

Critical vulnerability: Merchants receiving webhook callbacks have no mechanism to verify that the payload genuinely originated from Simpaisa. An attacker can send fabricated webhook payloads to a merchant's callback URL, spoofing payment confirmations or status updates. For a payment gateway, this directly enables financial fraud.

8.2 Gaps

ID	Gap	Severity
WH-G1	No webhook signature — merchants cannot verify payload authenticity	Critical
WH-G2	No replay protection — captured webhooks can be replayed	High
WH-G3	No timestamp in webhook payload for freshness verification	High
WH-G4	Merchant callback URL not restricted to HTTPS	Medium
WH-G5	No documented IP ranges for webhook source (merchants cannot firewall)	Medium
WH-G6	No retry/backoff policy documented	Low

8.3 Target State

Webhook Signing Specification:

Signature = HMAC-SHA256(webhook_secret, timestamp + "." + payload_body)
Header: X-Simpaisa-Signature: t=<unix_timestamp>,v1=<hex_signature>

Requirement	Specification
Algorithm	HMAC-SHA256
Secret	Per-merchant, 256-bit, generated by Simpaisa
Signed content	Unix timestamp (seconds) concatenated with "." and raw JSON body
Signature header	X-Simpaisa-Signature containing timestamp and signature
Timestamp tolerance	Merchants should reject webhooks older than 300 seconds
Replay protection	Include X-Simpaisa-Webhook-Id (unique per delivery attempt)
HTTPS enforcement	Callback URLs must use HTTPS; HTTP URLs rejected at registration
IP whitelisting	Publish and maintain Simpaisa webhook source IP ranges
Secret rotation	Support dual-secret validation during rotation window (72 hours)

Retry Policy:

Attempt	Delay	Max Attempts
1st retry	1 minute	—
2nd retry	5 minutes	—
3rd retry	30 minutes	—
4th retry	2 hours	—
5th retry	24 hours	—
Final	—	5 retries, then mark as failed + alert merchant

Merchant Verification SDK (provide to merchants):

# Example verification (Python)
import hmac, hashlib, time

def verify_webhook(payload_body, signature_header, secret):
    parts = dict(p.split("=", 1) for p in signature_header.split(","))
    timestamp = parts["t"]
    expected = parts["v1"]

    # Reject if older than 5 minutes
    if abs(time.time() - int(timestamp)) > 300:
        raise ValueError("Webhook timestamp too old")

    signed_content = f"{timestamp}.{payload_body}"
    computed = hmac.new(
        secret.encode(), signed_content.encode(), hashlib.sha256
    ).hexdigest()

    if not hmac.compare_digest(computed, expected):
        raise ValueError("Invalid webhook signature")

Priority: P0 — This is a fraud-enabling vulnerability.

---

9. OTP & Authentication Flows

9.1 Current State (Score: 4/10)

Control	Current Value	Industry Standard	Gap
OTP expiry	30 minutes	5 minutes maximum	6x too long
Max attempts	Undocumented	3 attempts then lock	Unknown enforcement
OTP length	Undocumented	6 digits minimum	Unknown
OTP generation	Undocumented	CSPRNG	Unknown
Rate limiting on OTP requests	Undocumented	3 per 5 minutes per number	Not enforced
OTP channel	SMS	SMS + fallback	Single channel
Lockout policy	Undocumented	Progressive lockout	Unknown

9.2 Gaps

ID	Gap	Severity
OTP-G1	30-minute OTP expiry window — 6x industry standard	Critical
OTP-G2	Maximum OTP verification attempts not documented or enforced	High
OTP-G3	No rate limiting on OTP request endpoint — enables SMS bombing	High
OTP-G4	OTP generation method not documented — may not use CSPRNG	Medium
OTP-G5	No progressive lockout after repeated failures	High
OTP-G6	OTP reuse policy not documented — may allow replay	Medium

9.3 Target State

OTP Specification:

Requirement	Specification
OTP length	6 digits
OTP generation	CSPRNG — no modulo bias; SecureRandom or equivalent
OTP expiry	5 minutes from generation (non-negotiable)
Max verification attempts	3 per OTP; on 3rd failure, OTP is invalidated
Rate limit — OTP request	3 requests per 5 minutes per mobile number
Rate limit — OTP verify	5 attempts per 15 minutes per mobile number
Progressive lockout	After 3 failed OTPs in sequence: 15-minute cooldown on new OTP requests
OTP reuse	Single-use; immediately invalidated on successful verification
OTP storage	Hashed (SHA-256) — never stored in plaintext
Logging	Log OTP request/verify events; never log the OTP value itself
Delivery confirmation	Integrate SMS delivery receipt; re-generate if delivery fails

Flow:

Customer → [Request OTP] → Simpaisa
    │
    ├── Rate limit check (3/5min per MSISDN)
    ├── Generate 6-digit OTP via CSPRNG
    ├── Hash and store with 5-minute TTL
    ├── Send via SMS gateway
    │
Customer → [Submit OTP] → Simpaisa
    │
    ├── Rate limit check (5/15min per MSISDN)
    ├── Attempt counter check (max 3 per OTP)
    ├── Hash submitted OTP and compare
    ├── On match: invalidate OTP, proceed
    └── On failure: increment counter, return generic error

Priority: P0 — The 30-minute window is an active, exploitable vulnerability.

---

10. Credential & Secret Management

10.1 Current State (Score: 6/10 with critical exception)

Control	Status	Detail
AWS Systems Manager Parameter Store	In use	Primary secret storage mechanism
Secrets in source control	CRITICAL FINDING	Surge deployment token committed in deploy.sh
Secret rotation	Not documented	No rotation schedule or automation
Secret scanning	Not implemented	No pre-commit hooks or CI pipeline scanning
Environment variable injection	Partial	Some services use Parameter Store; others unclear
Vault / dedicated secret manager	Not used	Parameter Store only (no audit trail on access)

10.2 Gaps

ID	Gap	Severity
CRED-G1	Surge token in deploy.sh — credential in source control	Critical
CRED-G2	No secret rotation schedule or automation	High
CRED-G3	No pre-commit secret scanning (e.g., gitleaks, trufflehog)	High
CRED-G4	No audit trail for secret access (Parameter Store lacks detailed audit)	Medium
CRED-G5	No distinction between merchant secrets and infrastructure secrets	Medium
CRED-G6	Database credentials management undocumented	High

10.3 Target State

Secret Management Architecture:

Secret Type	Storage	Rotation	Access
Merchant RSA keys	AWS KMS (CMK) + Parameter Store	12-month rotation	Service role only
Webhook HMAC secrets	Parameter Store (SecureString)	12-month rotation; dual-secret rollover	Service role only
Database credentials	AWS Secrets Manager (auto-rotation)	90-day automated rotation	Service role only; no human access
API keys (third-party)	AWS Secrets Manager	Per-provider policy; minimum 90 days	Service role only
Infrastructure tokens	AWS Secrets Manager	30-day rotation	CI/CD role only
TLS certificates	Caddy auto-renewal / Cloudflare	90-day automated	Automated; no human handling

Secret Scanning Pipeline:

Stage	Tool	Action
Pre-commit	gitleaks	Block commit if secret detected
CI pipeline	trufflehog	Fail build if secret detected in any commit
Repository scan	Bitbucket secret scanning	Alert on historical secrets
Runtime	AWS Config rules	Alert if Parameter Store values lack encryption

Immediate Actions:

1. Rotate the Surge token immediately — assume compromised.
2. Remove the token from deploy.sh and git history (use git filter-branch or BFG Repo Cleaner).
3. Move deployment credentials to CI/CD pipeline secrets (Bitbucket Pipelines variables).
4. Implement gitleaks pre-commit hook across all repositories.

Priority: P0 (Surge token rotation), P1 (rotation schedule, scanning pipeline)

---

11. Data Protection & PII

11.1 Current State (Score: 3/10 — CRITICAL)

Control	Status
PII classification	No documented data classification scheme
Encryption at rest	AWS default encryption (EBS, RDS) — not application-layer
PII masking in logs	Not implemented — PII visible in CloudWatch logs
Data retention policy	Not documented
Cross-border data flow mapping	Not documented
Right to erasure	Not documented
Data minimisation	Not enforced

11.2 Data Classification

Classification	Description	Examples	Controls Required
Restricted	Cardholder data; cryptographic keys	PAN, CVV, RSA private keys	AES-256 encryption; HSM storage; PCI DSS controls; no logging
Confidential	PII; financial data; authentication credentials	MSISDN, CNIC/NID, account numbers, transaction amounts, API keys	Encryption at rest; masking in logs; access logging; retention limits
Internal	Business data; operational data	Merchant configuration, transaction metadata, system metrics	Access control; no public exposure
Public	Published documentation; public API specifications	API docs, integration guides	Integrity protection only

11.3 PII Inventory

Data Element	Classification	Products	Jurisdictions	Masking Rule
Mobile number (MSISDN)	Confidential	All	All	Show last 4: ****1234
CNIC (Pakistan)	Confidential	Pay-Ins, Pay-Outs	PK	Show last 4: *****-*****-4
NID (Bangladesh)	Confidential	Pay-Ins, Pay-Outs	BD	Show last 4
PAN (card number)	Restricted	Cards	All	BIN + last 4: 4242****4242
CVV	Restricted	Cards	All	Never store; never log
Account number	Confidential	Pay-Outs, Remittances	All	Show last 4
Customer name	Confidential	All	All	Redact in logs
Email address	Confidential	All	All	Redact in logs
IP address	Confidential	All	All	Hash in long-term storage
Transaction amount	Confidential	All	All	Log permitted (operational need)

11.4 Cross-Border Data Flows

Simpaisa operates across jurisdictions with varying data protection requirements. Data flows must comply with the most restrictive applicable regime.

Jurisdiction	Regulator	Data Localisation Requirement	Key Regulation
Pakistan (PK)	SBP / PTA	Payment data must be processed and stored within Pakistan	SBP BPRD Circular; Prevention of Electronic Crimes Act 2016
Bangladesh (BD)	Bangladesh Bank	Transaction data localisation required	Bangladesh Bank guidelines; Digital Security Act 2018
Nepal (NP)	Nepal Rastra Bank	Data must reside in Nepal for domestic transactions	NRB IT Guidelines
Iraq (IQ)	CBI	Banking data subject to CBI oversight	CBI regulations
UAE (AE)	CBUAE / DIFC	DIFC has own data protection law; federal Personal Data Protection Law	Federal Decree Law No. 45 of 2021

Target Architecture for Data Residency:

• Per-jurisdiction data partitioning at the database level.
• No cross-border PII transfer without documented legal basis.
• Aggregate/anonymised data only at the regional reporting level.
• Encryption keys managed per jurisdiction.

11.5 Gaps

ID	Gap	Severity
DATA-G1	PII visible in application logs (CloudWatch)	Critical
DATA-G2	No data classification scheme applied	High
DATA-G3	No data retention or deletion policy	High
DATA-G4	Cross-border data flows not mapped or controlled	High
DATA-G5	No application-layer encryption at rest (relying on AWS defaults only)	Medium
DATA-G6	No right-to-erasure process	Medium
DATA-G7	Log retention period not defined	Medium

11.6 Target Controls

Control	Specification
Log masking	All PII masked before writing to any log destination; structured logging with PII redaction middleware
Encryption at rest	AES-256 for all Confidential and Restricted data at the application layer, in addition to AWS-managed encryption
Retention policy	Transaction records: per regulatory requirement (minimum 5 years PK/BD); PII: delete when no longer required; Logs: 90 days hot, 1 year cold, then delete
Cross-border controls	Data partitioned by jurisdiction; no PII crosses borders without documented legal basis
Right to erasure	Documented process; soft-delete with crypto-shredding for regulatory-retained records

Priority: P0 (PII in logs), P1 (classification, retention, cross-border)

---

12. Infrastructure Security

12.1 Current State

Control	Status	Detail
AWS WAF	Deployed	Edge-level web application firewall
AWS GuardDuty	Deployed	Threat detection for AWS accounts
AWS Parameter Store	In use	Secret storage (with noted exceptions)
Multi-AZ deployment	Yes	High availability across availability zones
API Gateway	Not deployed	No centralised gateway — each service directly exposed
CloudWatch	In use	Logging and basic monitoring only
Security event correlation	Not available	No SIEM; no cross-service event correlation
Infrastructure as Code	Not implemented	Infrastructure potentially managed manually
Network segmentation	Undocumented	VPC structure and security groups not documented
Container security	Unknown	Containerisation approach not documented
Patch management	Undocumented	OS and dependency patching cadence unknown

12.2 Gaps

ID	Gap	Severity
INFRA-G1	No API Gateway — no centralised authentication, rate limiting, or routing	Critical
INFRA-G2	No SIEM or security event correlation	High
INFRA-G3	No IaC — infrastructure changes are unauditable and unreproducible	High
INFRA-G4	Network segmentation not documented	High
INFRA-G5	No documented patch management process	Medium
INFRA-G6	No WAF rule documentation or tuning schedule	Medium
INFRA-G7	GuardDuty findings handling process not documented	Medium

12.3 Target State

Target Infrastructure Security Stack:

Internet
    │
    ├── Cloudflare (DDoS mitigation, bot management, geo-fencing, edge WAF, rate limiting)
    │
    ├── KrakenD API Gateway (authentication, authorisation, rate limiting, request validation)
    │
    ├── Application Services (Unikraft unikernels — minimal attack surface)
    │       └── Caddy sidecar (per-service mTLS, automatic certificate management)
    │
    ├── Data Layer (encrypted at rest, network-isolated, no public endpoints)
    │
    └── Observability (OpenTelemetry → security event pipeline → SIEM)

Network Segmentation (Target):

Zone	Purpose	Access
Edge	Cloudflare; public-facing	Internet-accessible
DMZ	KrakenD API Gateway	Cloudflare origins only
Application	Service workloads	Gateway only; no direct internet
Data	Databases, caches	Application zone only; no internet
Management	CI/CD, monitoring, admin tools	VPN/bastion only; MFA required

Infrastructure as Code:

Requirement	Specification
IaC tool	Terraform or Pulumi (with state encryption)
Code review	All infrastructure changes via PR; minimum 2 approvals
Drift detection	Automated; alert on manual changes
Secret handling	No secrets in IaC code; reference Parameter Store / Secrets Manager
Environment parity	Dev, staging, and production defined from same IaC modules

Unikraft Unikernels (Target):

Unikraft unikernels provide a dramatically reduced attack surface compared to traditional OS + container deployments: - No shell, no SSH, no package manager — eliminates entire classes of post-exploitation activity. - Single-address-space — no process injection. - Minimal syscall surface — only the syscalls the application needs. - Immutable at runtime — no on-host modification.

Priority: P0 (API Gateway deployment), P1 (IaC, network segmentation), P2 (unikernel migration)

---

13. Application Security

13.1 Current State

Control	Status
SAST (static analysis)	Not documented
DAST (dynamic analysis)	Not documented
Dependency scanning (SCA)	Not documented
Code review process	Not documented
Security-focused code review	Not documented
OWASP Top 10 coverage	Not systematically assessed

13.2 OWASP Top 10 (2021) Mapping

#	Category	Simpaisa Exposure	Current Mitigation	Gap
A01	Broken Access Control	High — IDOR not tested; flat merchant model	merchantId validation	No IDOR testing; no RBAC
A02	Cryptographic Failures	High — Pay-Ins unsigned; AES mode unknown	RSA signing on 3/4 products	Pay-Ins; AES configuration
A03	Injection	High — DB table names in docs aid SQLi	Unknown (no WAF rule docs)	No input validation docs; info leakage
A04	Insecure Design	Medium — inconsistent security across products	Per-product controls	No unified security architecture
A05	Security Misconfiguration	Medium — TLS versions undocumented	AWS defaults	No hardening baseline
A06	Vulnerable Components	Unknown — no dependency scanning	None documented	No SCA pipeline
A07	Auth Failures	Critical — Pay-Ins session-based; OTP 30-min	RSA on some products	Pay-Ins auth; OTP window
A08	Data Integrity Failures	High — unsigned webhooks	None for webhooks	Webhook signing
A09	Logging & Monitoring Failures	High — PII in logs; no SIEM	CloudWatch	PII masking; SIEM
A10	SSRF	Unknown	Unknown	Not assessed

13.3 Target Application Security Pipeline

Stage	Tool/Process	Trigger	Action on Finding
Pre-commit	gitleaks	Every commit	Block commit
PR / code review	Mandatory security checklist	Every PR	Reviewer verifies checklist
CI — SAST	SonarQube or Semgrep	Every build	Fail on Critical/High
CI — SCA	Snyk or Dependabot	Every build	Fail on Critical; alert on High
CI — Container scan	Trivy	Every image build	Fail on Critical
Pre-deploy — DAST	OWASP ZAP	Staging deployment	Block production deploy on Critical
Production	Runtime application self-protection (future)	Continuous	Alert + block
Quarterly	Manual penetration test	Scheduled	Remediate within SLA

Secure Coding Standards:

Language	Standard
Java (existing)	OWASP Java Security Cheat Sheet; no raw SQL; parameterised queries only
Rust (target — crypto)	unsafe blocks require explicit justification and review; cargo audit in CI
TypeScript (target — services)	Strict mode; no any types for external input; Zod schema validation

Priority: P1

---

14. PCI DSS Scope

14.1 Current State

Aspect	Status
PCI DSS applicability	Cards product processes cardholder data (PAN, CVV, expiry)
Current compliance level	Compliant (per Cards product security controls)
Scope boundary	Undocumented — unclear which systems are in-scope
SAQ vs ROC	Undocumented
QSA engagement	Undocumented
Network segmentation for scope reduction	Undocumented

14.2 PCI DSS Scope Definition (Target)

In-Scope Systems:

Component	Reason	PCI DSS Requirement
Cards API service	Processes/transmits cardholder data	Full scope
KrakenD Gateway (Cards routes)	Transmits cardholder data	Req 1, 2, 6, 7, 8, 10, 11, 12
Database (Cards schema)	Stores cardholder data	Full scope
HSM / key management	Encrypts cardholder data	Req 3, 6, 7, 8, 10
Logging infrastructure (Cards events)	May contain cardholder data references	Req 10
Network segments carrying card data	Transmits cardholder data	Req 1

Out-of-Scope Systems (with segmentation):

Component	Justification
Pay-Ins service	Does not process cardholder data
Pay-Outs service	Does not process cardholder data
Remittances service	Does not process cardholder data
Corporate systems	Network-segmented; no cardholder data access

Compliance Approach:

Assessment Type	Applicability	Frequency
SAQ D (Service Provider)	If < threshold volume	Annual
ROC (Report on Compliance)	If > threshold volume or required by acquirer	Annual
ASV scan	All internet-facing in-scope systems	Quarterly
Penetration test	CDE and segmentation controls	Annual (minimum)
Internal vulnerability scan	All in-scope systems	Quarterly

14.3 Key PCI DSS Requirements Mapping

Req	Title	Current Status	Gap
1	Network security controls	Partial — AWS SGs, WAF	Segmentation not documented
2	Secure configurations	Unknown	No hardening baseline
3	Protect stored account data	AES encryption for card data	AES mode/IV undocumented
4	Protect data in transit	mTLS for Cards	TLS configuration not audited
5	Malware protection	Unknown	Not documented
6	Secure systems and software	Unknown	No SDLC documentation
7	Restrict access	Unknown	No RBAC documented
8	Identify users	RSA signing + mTLS	Cards-specific; strong
9	Physical access	N/A (cloud)	AWS SOC2 covers
10	Log and monitor	CloudWatch	PII masking; no SIEM
11	Test security	Unknown	No pen test cadence documented
12	Security policies	Unknown	This document begins to address

Priority: P1 (scope documentation), P2 (gap remediation per QSA findings)

---

15. Incident Response

15.1 Current State

No documented incident response plan was identified during the architectural review.

15.2 Target Incident Response Framework

Severity Definitions:

Severity	Definition	Examples	Response Time	Escalation
SEV-1 (Critical)	Active exploitation; data breach; complete service outage; financial loss occurring	Credential compromise; cardholder data exfiltration; payment fraud via unsigned webhooks	15 minutes to acknowledge; all-hands war room	CDO + CEO immediately; regulators within required timeframe
SEV-2 (High)	Vulnerability with imminent exploitation risk; partial service degradation with security implications	Zero-day in production dependency; brute-force attack in progress; secret exposure in public repo	1 hour to acknowledge; dedicated responder	CDO within 1 hour; CTO immediately
SEV-3 (Medium)	Vulnerability identified but not actively exploited; security control failure without immediate impact	Failed SAST finding in production; expired certificate; GuardDuty alert (non-critical)	4 hours to acknowledge	Engineering lead within 4 hours
SEV-4 (Low)	Minor security issue; policy violation without direct risk	Dependency with known low-severity CVE; minor configuration drift	Next business day	Tracked in backlog

Incident Response Phases:

Phase	Activities	Owner
Detection	Monitoring alerts; GuardDuty findings; merchant reports; pen test findings	On-call engineer
Triage	Severity classification; scope assessment; initial containment decision	Security lead
Containment	Isolate affected systems; revoke compromised credentials; block attack vectors	Engineering team
Eradication	Remove attacker access; patch vulnerability; rotate all potentially compromised secrets	Engineering team
Recovery	Restore service; verify integrity; enhanced monitoring	Engineering + Ops
Post-Incident	Root cause analysis; lessons learned; control improvements; regulatory notification if required	CDO

Communication Matrix:

Audience	SEV-1	SEV-2	SEV-3	SEV-4
CDO (Daniel O'Reilly)	Immediate	1 hour	Daily summary	Weekly summary
CEO	Immediate	4 hours	As needed	N/A
Affected merchants	Within 4 hours	Within 24 hours	As needed	N/A
Regulators (SBP, BB, etc.)	Per regulatory requirement (typically 24-72 hours)	Per regulatory requirement	N/A	N/A
Legal counsel	Immediate for data breach	As needed	N/A	N/A

Priority: P1

---

16. Security Monitoring & Logging

16.1 Current State

Control	Status
Application logging	CloudWatch (basic)
Infrastructure logging	CloudWatch + GuardDuty
Security event correlation	Not implemented
SIEM	Not deployed
Alerting	Basic CloudWatch alarms
Audit trail	Partial (CloudTrail for AWS API calls)
Log integrity	Not documented
PII in logs	Present — no masking

16.2 What to Log (Security Events)

Event Category	Events	Severity	Retention
Authentication	Login success/failure; API key usage; mTLS cert presented; signature verification result	All events	1 year
Authorisation	Access denied; privilege escalation attempt; IDOR attempt; out-of-scope resource access	All events	1 year
Transaction	Transaction initiated, completed, failed, reversed; amount; merchantId; status	All events	Per regulation (5+ years)
Configuration	Merchant config change; webhook URL update; API key generation/revocation; user role change	All events	2 years
Security	Rate limit triggered; WAF block; GuardDuty finding; OTP failure; brute-force detection	All events	1 year
Infrastructure	Deployment; instance launch/termination; security group change; Parameter Store access	All events	1 year
Error	Unhandled exception; 5xx response; timeout; circuit breaker trip	All events	90 days

What NEVER to Log:

Data	Reason
Card numbers (PAN)	PCI DSS Req 3
CVV / CVC	PCI DSS Req 3
OTP values	Security
Passwords / secrets	Security
Full CNIC / NID	Data protection
RSA private keys	Security
Unmasked MSISDN	Data protection

16.3 Target Monitoring Architecture

Application Services
    │
    ├── OpenTelemetry SDK (structured logs, traces, metrics)
    │
    ├── OpenTelemetry Collector
    │       ├── PII redaction processor (before export)
    │       ├── Security event tagging
    │       └── Export to:
    │               ├── Log storage (CloudWatch / S3)
    │               ├── SIEM (security events)
    │               └── Metrics (Prometheus/Grafana)
    │
    └── SIEM / Security Analytics
            ├── Correlation rules
            ├── Anomaly detection
            ├── Alerting → PagerDuty / Slack
            └── Dashboard (security posture)

Critical Alerting Rules (Target):

Alert	Condition	Severity
Brute-force detection	> 10 auth failures from same IP in 5 minutes	SEV-2
Credential stuffing	> 50 auth failures across different merchantIds from same IP range in 10 minutes	SEV-1
Signature verification failure spike	> 5% of requests failing signature verification in 5-minute window	SEV-2
Rate limit breach	Sustained rate limit triggering for > 10 minutes	SEV-3
GuardDuty high-severity	GuardDuty finding with severity > 7	SEV-2
Secret access anomaly	Parameter Store / Secrets Manager access from unexpected role	SEV-2
Data exfiltration indicator	Unusual volume of transaction data queries	SEV-1
Certificate expiry	Certificate expiring within 7 days	SEV-3

Priority: P1 (PII redaction in logs), P2 (SIEM, correlation rules)

---

17. Vulnerability Management

17.1 Current State

Control	Status
Penetration testing	Not documented
Vulnerability scanning	GuardDuty (infrastructure level)
Dependency scanning	Not documented
Bug bounty programme	Not implemented
Patch management	Undocumented
Vulnerability disclosure process	Not documented

17.2 Target Vulnerability Management Programme

Penetration Testing:

Type	Scope	Frequency	Provider
External network pen test	All internet-facing endpoints	Bi-annual	Third-party (CREST/OSCP certified)
Application pen test	All product APIs + merchant portal	Annual	Third-party
PCI DSS pen test	Cardholder data environment	Annual	QSA-approved
Red team exercise	Full scope including social engineering	Annual	Third-party
Internal pen test	Internal services, databases, admin interfaces	Annual	Third-party or internal

Vulnerability SLAs:

Severity	Remediation SLA	Verification
Critical (CVSS 9.0-10.0)	48 hours	Re-test within 7 days
High (CVSS 7.0-8.9)	7 days	Re-test within 14 days
Medium (CVSS 4.0-6.9)	30 days	Re-test within 45 days
Low (CVSS 0.1-3.9)	90 days	Next scheduled scan

Patch Management:

Component	Patch Cadence	Critical Patch SLA
Operating system	Monthly	48 hours
Application dependencies	Weekly scan; monthly update	48 hours for critical CVE
Container base images	Monthly rebuild	48 hours for critical CVE
WAF rules	As published by vendor	24 hours for active exploitation

Bug Bounty Consideration:

Aspect	Recommendation
Programme type	Private (invite-only) initially; public after 12 months of maturity
Platform	HackerOne or Bugcrowd
Scope	Production APIs only; exclude internal admin
Rewards	$100-$5,000 based on severity and impact
Prerequisites	Must first remediate all known Critical/High findings

Priority: P1 (pen testing cadence), P2 (bug bounty programme)

---

18. Third-Party / Vendor Security

18.1 Current State

Simpaisa integrates with multiple third-party payment channels, banks, and mobile money operators across six jurisdictions. The security posture of these integrations is not systematically assessed or documented.

18.2 Third-Party Risk Categories

Category	Examples	Risk Level
Payment channel partners	Telcos (Jazz, Telenor, Robi, etc.), banks, mobile money operators	High — handle financial data
Infrastructure providers	AWS, Cloudflare (target)	High — platform availability
Software dependencies	Open-source libraries, frameworks	Medium — supply chain risk
Identity providers	ControlPlane.com (target)	High — authentication
Monitoring/observability	CloudWatch, OpenTelemetry backends	Medium — operational data

18.3 Target Vendor Security Requirements

Before Integration:

Check	Requirement
Security assessment	Vendor security questionnaire (SIG Lite or equivalent)
Compliance verification	PCI DSS, ISO 27001, SOC 2 as applicable
Data handling review	Where is Simpaisa's data stored, processed, transmitted?
Incident response capability	Vendor must have documented IR process
SLA review	Uptime, incident notification, breach notification

Ongoing:

Control	Frequency
SLA monitoring	Continuous (automated)
Compliance certificate renewal	Annual
Security questionnaire refresh	Annual
Access review	Quarterly
API credential rotation	Per credential management policy (Section 10)
Vendor incident response test	Annual

Payment Channel Partner Monitoring:

Metric	Threshold	Action
Channel uptime	< 99.5% over rolling 7 days	Escalate to partner; activate fallback
Error rate	> 5% over 1 hour	Alert; investigate
Response time (P95)	> 10 seconds	Alert; investigate
Settlement discrepancy	Any	Immediate investigation
Certificate expiry	< 30 days	Alert partner; escalate at 14 days

Priority: P2

---

19. Compliance Matrix

19.1 Regulatory Landscape

Jurisdiction	Primary Regulator	Payment Regulation	Data Protection	Simpaisa Products
Pakistan (PK)	State Bank of Pakistan (SBP)	SBP Payment Systems regulations; BPRD circulars; EMI regulations	Prevention of Electronic Crimes Act 2016; PTA regulations	Pay-Ins, Pay-Outs, Remittances, Cards
Bangladesh (BD)	Bangladesh Bank	Payment and Settlement Systems Regulations 2014; MFS regulations	Digital Security Act 2018; ICT Act	Pay-Ins, Pay-Outs, Remittances
Nepal (NP)	Nepal Rastra Bank (NRB)	NRB Payment Systems regulations; Digital Payment regulations	Individual Privacy Act 2018	Pay-Ins, Pay-Outs, Remittances
Iraq (IQ)	Central Bank of Iraq (CBI)	CBI Payment Systems regulations; Electronic Payment regulations	Iraqi data protection framework	Pay-Ins, Pay-Outs, Remittances
UAE (AE)	CBUAE / DIFC / ADGM	CBUAE Stored Value Facilities regulations; DIFC/ADGM licensing	Federal Personal Data Protection Law (2021); DIFC Data Protection Law	Corporate HQ; Remittances (corridor)

19.2 Cross-Regulatory Compliance Requirements

Requirement	PCI DSS	SBP	BB	NRB	CBI
Data encryption in transit	Req 4	Required	Required	Required	Required
Data encryption at rest	Req 3	Required	Required	Required	Required
Access control	Req 7, 8	Required	Required	Required	Required
Audit logging	Req 10	Required	Required	Required	Required
Vulnerability management	Req 5, 6, 11	Required	Required	Recommended	Recommended
Incident reporting	Req 12	24 hours	24 hours	48 hours	As required
Data localisation	N/A	Required	Required	Required	Varies
Annual security audit	Req 11, 12	Required	Required	Required	Required
Business continuity	Req 12	Required	Required	Required	Required
Customer data protection	Req 3, 4	Required	Required	Required	Required

19.3 Compliance Gaps

ID	Requirement	Regulation(s)	Current Status	Gap
COMP-G1	Comprehensive audit logging	All	Partial (CloudWatch, PII issues)	No SIEM; PII in logs
COMP-G2	Data localisation	SBP, BB, NRB	Undocumented	Data residency not mapped
COMP-G3	Incident reporting process	All	Not documented	No IR plan; no regulatory notification process
COMP-G4	Annual security audit	All	Not documented	No pen test cadence
COMP-G5	Data protection (PII)	All	Non-compliant	No masking, no retention policy
COMP-G6	Business continuity plan	All	Multi-AZ (partial)	No documented BCP
COMP-G7	Customer consent / privacy notice	PDPL (AE)	Unknown	Not assessed

Priority: P0 (incident reporting, data protection), P1 (compliance audit, localisation)

---

20. Security Remediation Roadmap

20.1 Overview

The remediation roadmap is organised into three phases aligned with the broader architectural transformation. Each item references the specific gap identified in this document.

20.2 Phase 1 — Critical Security Fixes (Months 1-3)

Objective: Eliminate active vulnerabilities that represent immediate fraud or breach risk.

#	Remediation	Gap Ref	Priority	Effort	Risk Mitigated
1.1	Implement RSA-SHA256 request signing for Pay-Ins	AUTH-G1	P0	High	Request forgery on highest-volume product
1.2	Implement HMAC-SHA256 webhook signing	WH-G1	P0	Medium	Payment status spoofing / fraud
1.3	Reduce OTP expiry to 5 minutes; implement 3-attempt lockout	OTP-G1, G2	P0	Low	OTP brute-force
1.4	Rotate and remove Surge token from source control	CRED-G1	P0	Low	Infrastructure credential exposure
1.5	Implement rate limiting on all endpoints	API-G1	P0	Medium	DoS, brute-force, credential stuffing
1.6	Remove database table names from merchant documentation	API-G2	P0	Low	SQL injection reconnaissance
1.7	Implement PII masking in application logs	DATA-G1	P0	Medium	Data breach via log exposure
1.8	Implement gitleaks pre-commit hooks across all repositories	CRED-G3	P0	Low	Future secret exposure prevention
1.9	Document and enforce TLS 1.2+ with approved cipher suites	TLS-G1, G3	P1	Low	Downgrade attacks
1.10	Document incident response plan	COMP-G3	P1	Medium	Regulatory compliance; response readiness

20.3 Phase 2 — Platform Security (Months 3-9)

Objective: Deploy centralised security infrastructure and establish security processes.

#	Remediation	Gap Ref	Priority	Effort	Risk Mitigated
2.1	Deploy KrakenD API Gateway with centralised authentication	INFRA-G1, AUTH-G7	P0	High	Centralised enforcement; consistent security
2.2	Deploy Cloudflare for edge security	INFRA-G1	P1	Medium	DDoS, bot management, geo-fencing
2.3	Implement ControlPlane.com for identity/RBAC	AUTHZ-G2, G3	P1	High	Access control; API key lifecycle
2.4	Implement mTLS for all product lines via Caddy	TLS-G2, AUTH-G1	P1	Medium	Transport authentication
2.5	Deploy SAST/SCA in CI pipeline	APP-SEC	P1	Medium	Vulnerable code/dependencies
2.6	Implement secret rotation automation	CRED-G2	P1	Medium	Stale credentials
2.7	Establish penetration testing programme	VUL-MGMT	P1	Medium	Unknown vulnerabilities
2.8	Document data classification and retention policy	DATA-G2, G3	P1	Medium	Data protection compliance
2.9	Map cross-border data flows	DATA-G4, COMP-G2	P1	Medium	Regulatory compliance
2.10	Implement replay protection (timestamp + nonce)	AUTH-G2	P1	Medium	Replay attacks
2.11	Deploy OpenTelemetry with PII redaction	MON-G1	P1	Medium	Observability without data exposure
2.12	Implement Infrastructure as Code	INFRA-G3	P1	High	Auditability; reproducibility

20.4 Phase 3 — Hardening & Maturity (Months 9-18)

Objective: Achieve security maturity; prepare for advanced threats; complete compliance programmes.

#	Remediation	Gap Ref	Priority	Effort	Risk Mitigated
3.1	Deploy SIEM with correlation rules	INFRA-G2	P2	High	Advanced threat detection
3.2	Migrate cryptographic operations to Rust	CRYPTO	P2	High	Memory safety in security-critical code
3.3	Begin Unikraft unikernel migration	INFRA	P2	High	Reduced attack surface
3.4	Launch private bug bounty programme	VUL-MGMT	P2	Medium	Crowdsourced vulnerability discovery
3.5	Implement IDOR automated testing	AUTHZ-G1	P2	Medium	Access control validation
3.6	PCI DSS scope documentation and gap assessment	PCI	P2	Medium	Compliance readiness
3.7	Vendor security assessment programme	VENDOR	P2	Medium	Third-party risk
3.8	Red team exercise	VUL-MGMT	P2	High	Real-world attack simulation
3.9	Fix Remittances header typo (remitance → remittance)	AUTH-G6	P3	Low	Technical debt; requires merchant coordination
3.10	Certificate pinning for mobile integrations	TLS-G6	P3	Low	MITM on mobile

20.5 Remediation Summary

Phase	Items	P0	P1	P2	P3	Timeframe
Phase 1	10	8	2	0	0	Months 1-3
Phase 2	12	1	11	0	0	Months 3-9
Phase 3	10	0	0	8	2	Months 9-18
Total	32	9	13	8	2	18 months

---

21. Appendix: Security Controls Checklist

21.1 Per-Product Security Controls Status

Control	Pay-Ins	Pay-Outs	Remittances	Cards	Target
RSA request signing	No	Yes	Yes	Yes	All
mTLS	No	Yes	Unconfirmed	Yes	All
Field-level encryption	No	No	No	Yes (AES)	Cards only
Replay protection	No	No	No	No	All
Rate limiting	Undocumented	Undocumented	Undocumented	Undocumented	All
Input validation	Undocumented	Undocumented	Undocumented	Undocumented	All
Idempotency	Undocumented	Undocumented	Undocumented	Undocumented	All
Webhook signing	No	No	No	No	All
PII log masking	No	No	No	No	All
Error sanitisation	No (DB names leaked)	Unknown	Unknown	Unknown	All

21.2 Infrastructure Security Controls Status

Control	Current	Target
Edge DDoS protection	AWS WAF	Cloudflare
API Gateway	None	KrakenD
WAF	AWS WAF (rule config undocumented)	Cloudflare WAF + KrakenD validation
Identity provider	None (per-service)	ControlPlane.com
Secret management	Parameter Store (partial)	AWS Secrets Manager + KMS
Secret scanning	None	gitleaks + trufflehog
SAST	None	SonarQube / Semgrep
DAST	None	OWASP ZAP
SCA (dependencies)	None	Snyk / Dependabot
Container scanning	None	Trivy
SIEM	None	Target TBD
IaC	None	Terraform / Pulumi
Pen testing	Undocumented	Bi-annual external; annual application
Certificate management	Manual	Caddy auto-TLS + Cloudflare
Network segmentation	Undocumented	Zone-based (edge/DMZ/app/data/mgmt)
Monitoring	CloudWatch (basic)	OpenTelemetry → SIEM
Threat detection	GuardDuty	GuardDuty + SIEM correlation

21.3 Compliance Controls Status

Control	PCI DSS	SBP	BB	NRB	CBI	Status
Encryption in transit	Req 4	Yes	Yes	Yes	Yes	Partial (mTLS not universal)
Encryption at rest	Req 3	Yes	Yes	Yes	Yes	AWS-level only
Access control	Req 7,8	Yes	Yes	Yes	Yes	No RBAC
Audit logging	Req 10	Yes	Yes	Yes	Yes	PII issues
Vulnerability mgmt	Req 5,6,11	Yes	Yes	Rec	Rec	Not documented
Incident reporting	Req 12	24h	24h	48h	TBD	No IR plan
Data localisation	N/A	Yes	Yes	Yes	Varies	Not mapped
Annual audit	Req 11,12	Yes	Yes	Yes	Yes	Not documented

---

Document Control

Version	Date	Author	Changes
1.0	2 April 2026	Daniel O'Reilly, CDO	Initial version — populated from Architectural Review findings

Review Schedule: Quarterly, or upon significant architectural change.

Next Review: July 2026

Distribution: Simpaisa Leadership Team, Engineering Leads, Security Team

---

This document contains confidential security information about Simpaisa's infrastructure and controls. Distribution must be limited to authorised personnel only.