5.7 Security, IAM, audit

The shape

Security and audit are first-class architectural concerns. The RBI IT Master Direction (2.13) plus the Outsourcing MD (2.14) plus DPDP (2.12) together set the bar. This page describes the architectural shape; specific controls are detailed in 14.5 Security and compliance.

Identity and access

Internal users (employees, analysts, admins)

SSO via Google Workspace / Microsoft Entra ID / Okta.
OIDC to the platform’s auth service.
MFA mandatory for every login.
No local passwords for internal users.
TOTP preferred; hardware keys (YubiKey) for privileged accounts.

Borrower auth

Mobile OTP for the borrower portal (consumer borrower) and Aadhaar OTP for V-CIP and eSign flows (specific to product needs).
MPIN / biometric for mobile app (if shipped).
OAuth-style consent flow for embedded scenarios where partner UI initiates.

Partner auth (co-lending, embedded)

mTLS for partner-to-platform API integrations — partner certificate verified against allow-list.
API key + signed request (HMAC) for additional authentication.
Per-partner credentials rotated periodically; rotation automated.

RBAC

Role library modelled after operations — borrower-ops, credit-analyst, credit-supervisor, ops-supervisor, collections-agent, collections-supervisor, compliance-officer, internal-auditor, admin, etc.
Permissions granular: read / write / approve / delete; scoped to module + entity + status.
Tenant scoping for multi-tenant operation (relevant when productisation begins).
Periodic access review — quarterly per IT MD; system surfaces user-permission matrix for review.

Joiner / mover / leaver

Lifecycle	Action
Joiner	New user request → manager approval → provisioning via SSO → role assignment
Mover	Role change → access review for new role → old permissions revoked
Leaver	Access revoked across all systems within `1 hour` of HRMS update; audit confirms

The platform integrates with HRMS for joiner / mover / leaver triggers where possible; for new platforms without HRMS integration, a manual but auditable workflow.

Secrets management

Vault (HashiCorp Vault) or AWS Secrets Manager + KMS.
No secrets in code, no secrets in env files committed to repo, no secrets in container images.
Automatic rotation for vendor API keys where the vendor supports rotation; manual rotation on a documented schedule otherwise.
Audit log of every secret read.
Break-glass procedure for emergency credential access, fully audited.

Encryption

In transit: TLS 1.2+ for all external; mTLS for internal sensitive paths in production.
At rest:
- DB: AES-256 with KMS-managed keys.
- Object store: SSE-KMS.
- Backups: encrypted with separate KMS keys (defence in depth).
In memory: KMS-managed crypto material; not persisted in plaintext.

PII handling — the vault pattern

PII tokenisation is the single most important architectural pattern for compliance and security.

Pattern

PII vault as a separate service with isolated database.
Tokenisation API: accepts clear PII; returns opaque token; stores clear text encrypted in vault.
Detokenisation API: callable only by services with explicit need (RBAC + audit per call).
Tokens in main DB: every reference to PII is a token, never clear text.
Masking in logs: log scrubbers strip PII from log lines; CI tests that no production code logs clear PII.
Masking in dashboards: non-need-to-know roles see masked values (e.g., XXX1234XXXX for PAN).

Pieces of PII that get tokenised

PAN.
Aadhaar number / VID / Aadhaar reference.
Mobile.
Email.
Bank account number.
Promoter / director DoB (combined with name, often).
Borrower address (sometimes; partial masking sufficient for most needs).

Pieces that aren’t tokenised (per regulatory requirement to retain)

KYC documents themselves (in object store with strict access).
Display names (used for UI; if highly sensitive can be tokenised additionally).

Audit log

Every state-affecting action emits an audit event:

actor_user_id or actor_service_id.
action, resource_type, resource_id.
before_state_json, after_state_json.
request_ip, request_user_agent.
timestamp.
prev_hash, this_hash — hash chain for integrity.

Hash chain

Each audit event includes a hash of itself plus the hash of the previous event. Tampering with any event invalidates every subsequent event’s hash, making tampering detectable.

event_n.this_hash = SHA-256(
    event_{n-1}.this_hash ||
    event_n.actor ||
    event_n.action ||
    event_n.resource_type ||
    event_n.resource_id ||
    event_n.timestamp
)

A daily integrity check recomputes the chain and alerts on mismatch.

Storage

Raw events in OLTP for query speed.
Periodic archival to S3 with Object Lock (Compliance mode) for long-term retention.
Retention per regulatory requirement — typically 8 – 10 years for lending data.

Searchable

OpenSearch index on audit metadata for ops / auditor search.

Application security

Secure SDLC: security review at design, code review with security checklist, SAST in CI, DAST in pre-prod, SCA (dependency vulnerabilities) continuous.
Annual external pen test per IT MD.
Bug bounty programme at scale (recommended once platform is public).
Vulnerability management: defined SLAs per severity (Critical <= 7 days; High <= 30 days).
Container security: image scanning, signing, minimal base images.

Infrastructure security

Network segmentation: public / DMZ / private / restricted subnets.
Bastion + SSH-via-SSO only for admin access; no direct SSH from public.
Egress control: outbound vendor traffic via egress proxy with allowlist.
Endpoint security: managed endpoints for employees; DLP controls.
SIEM / SOC: log aggregation; threat detection; 24×7 on-call (internal or outsourced) for production incidents.

Incident response

Runbook per incident type — security, vendor, infrastructure, data-quality, regulatory.
On-call rotation.
Severity classification (P0 / P1 / P2 / P3).
Material cyber incident reported to RBI within <= 6 hours per IT MD + CERT-In direction.
Post-incident review (RCA) mandatory for P0 / P1; preventive actions tracked.
Learnings shared across team.

Cloud-specific security

Multi-account isolation — prod / pre-prod / dev / security / audit in separate AWS accounts.
AWS Organizations for centralised guardrails (SCPs).
CloudTrail centralised for all accounts.
Cloud-config drift detection (AWS Config / Prowler / Wiz).
IaC (Terraform) for everything; manual changes prohibited and detected.
GuardDuty / Security Hub for continuous monitoring.

RBI IT MD alignment

Every architectural control above maps to a clause in the RBI IT MD (Nov 2023). The team maintains a control mapping document:

RBI IT MD clause	Platform control	Evidence	Owner
IT Governance	Board-approved IT strategy	Board minutes	CIO
Information Security	Information Security Policy v3	Policy document; access via portal	InfoSec
Access Management	SSO + MFA + RBAC	SSO config; access review reports	InfoSec
Cryptography	TLS 1.2+; AES-256; KMS	Cert manifest; KMS inventory	InfoSec
Incident Reporting	RBI report `<= 6 hours`	Incident response runbook + drill records	InfoSec
Outsourcing	Vendor master + MSA + audit rights	Vendor inventory + MSA repository	Vendor mgmt
Audit	Hash-chained audit log	Daily integrity report	InfoSec + Internal Audit
BCP / DR	Documented + drilled	Drill reports quarterly	InfoSec + IT

The mapping is reviewed during external IT audit annually.

What’s intentionally out of scope of this page

ISO 27001 certification — recommended at year 2 once stable.
SOC 2 — relevant when SaaS productisation begins.
PCI DSS — only if card-data is handled (payment gateway abstracts this; usually out of scope for the lender).
HIPAA / GDPR — not applicable to Indian-only lending.

2.13 IT and cybersecurity Master Direction — the regulatory text.
2.14 Outsourcing MD — vendor governance.
2.12 DPDP Act 2023 — data protection law.
14.5 Security and compliance stack — concrete tools.
13.20 Security backlog — engineering tasks.