← All documents
The authoritative security and compliance control catalogue for the Sindh IT Portal — Facilitation Desk (SITP): threat model, authentication and authorization, cryptography, secrets, input/output controls, audit, privacy, records and archival, RTI compliance, cybersecurity posture, government-audit readiness, and breach response.
This document is the single source of truth for security and compliance controls of SITP. It is consumed by engineering (for control implementation), by QA (for acceptance), by the independent security assessor (for ASVS L2 verification, see NFR-SEC-001), by internal audit and the Auditor-General / Public Accounts Committee (for evidence), and by the PPP contract (MAAHIR / Server4Sale) as the security baseline.
Every control is written as a row in a per-domain table:
| Col |
Meaning |
ID |
Stable SEC-<nnn>, never translated, never renumbered |
Control |
One imperative sentence: what the system shall do |
[M|S|C] |
MoSCoW priority (_conventions.md §5) |
Trace |
NFR(s) and/or architecture sections this control satisfies |
| Domain |
Coverage |
TM |
Threat modeling |
AUTHN |
Authentication |
AUTHZ |
Authorization |
SESS |
Session management |
CRYPTO |
Cryptography |
SECRET |
Secrets management |
IVOE |
Input validation & output encoding |
WAF |
WAF, rate limiting, abuse |
HDR |
Secure headers |
SCA |
Dependency / SBOM / vulnerability scanning |
AUD |
Audit logging |
PRIV |
Data protection & privacy |
REC |
Records management & archival |
RTI |
Sindh RTI Act 2016 compliance |
POST |
Cybersecurity posture (pen-test, CERT-PK, CII, IR) |
GAUD |
Government audit readiness (AG/PAC, finance) |
AR |
Access reviews & recertification |
SSDLC |
Secure SDLC & CI/CD |
MON |
Logging / monitoring / SIEM |
BR |
Breach notification & forensics |
The measurable thresholds live in /specs/en/03-non-functional-reqs/ §3.4 (SEC), §3.5 (PRIV), §3.12 (COMP), §3.13 (AUD). This document defines the controls that meet those thresholds. Where a control and an NFR overlap, the NFR states the number and this document states how it is achieved.
SITP is engineered security-by-design (see /specs/en/15-tech-architecture/ §1 principle 8 and §16). The controls below operationalise nine tenets that govern every decision in this catalogue.
| # |
Principle |
How it manifests in SITP |
| 1 |
Secure by default |
Every capability ships dark behind a feature flag; default-deny at WAF and at RBAC; least privilege at every layer. |
| 2 |
Defence in depth |
WAF → API guard → data-layer scoping → field-level encryption → audit. No single control is load-bearing alone. |
| 3 |
Least privilege |
Roles grant the minimum permissions for the task; ABAC further narrows confidential/VIP reads to named watchers and the escalation chain. |
| 4 |
Zero trust |
Every request is authenticated, authorized, and logged at the boundary; no implicit trust between tiers. Internal service-to-service calls carry credentials and run over TLS within the host network. |
| 5 |
Data minimisation & residency |
Collect only what is justified; keep PII and sovereign data (CNIC, NADRA payloads) within Pakistan; redact before any cloud AI call. |
| 6 |
Separation of duties |
Sensitive actions (closing VIP tickets, exporting PII, toggling flags, break-glass) require step-up auth and, where applicable, a second approver. |
| 7 |
Auditable & tamper-evident |
Every state change and every read of sensitive data is captured in an append-only, hash-chained audit log exported off-host. |
| 8 |
Fail safe |
Errors deny access, never grant it; circuit breakers degrade capabilities rather than opening bypasses; AV scan failure quarantines the file. |
| 9 |
Assume breach |
The design assumes a component may be compromised; blast radius is bounded by per-field encryption, row-level scoping, token lifetimes, and revocation. |
SITP is a public-facing provincial government system that accepts inbound traffic from the open internet (citizens, company representatives), authenticates government staff across multiple departments, integrates with sovereign government systems (NADRA, SECP, FBR, SRB, PSEB, NITB e-Office), processes PII and sovereign data, and uses pluggable cloud and on-prem AI/OCR engines. The threat model below applies the STRIDE taxonomy (Microsoft) across the trust boundaries of the system: internet → edge, edge → application, application → stateful backends, application → external integrations, application → AI/OCR engines, staff → citizen data, and operator → production.
| Boundary |
Crossing parties |
Primary risk classes |
| Internet → nginx edge |
Anonymous / authenticated citizens, company reps, partners |
Spoofing, DoS, info disclosure, tampering (injection) |
| Edge → NestJS API |
Edge forwards user requests + OIDC tokens |
Elevation of privilege, repudiation |
| API → MariaDB / Redis / MinIO / Meilisearch |
Internal services |
Tampering, info disclosure, repudiation |
| API → External integrations (NADRA, SECP, …) |
Outbound sovereign calls |
Info disclosure, spoofing (fake callbacks), tampering |
| API / Workers → AI / OCR engines |
Cloud or on-prem |
Info disclosure (PII egress), repudiation (un-audited calls) |
| Staff → citizen / company data |
Authenticated privileged users |
Info disclosure (curiosity reads), elevation, repudiation |
| Operator (MAAHIR / Server4Sale) → production |
DevOps, DBAs |
Tampering, info disclosure, elevation (break-glass abuse) |
| Threat class |
Example in SITP |
Mitigations (control IDs) |
| Spoofing |
Attacker uses stolen staff credentials to log in as a Section Officer; forged inbound webhook impersonates NADRA/WhatsApp; forged AI-service token. |
SEC-003 (Keycloak OIDC), SEC-005 (mandatory 2FA staff), SEC-006 (step-up), SEC-030 (SSRF + outbound mTLS/HMAC), SEC-023 (no shared secrets in code), SEC-031 (WAF bot/abuse). |
| Tampering |
SQLi or mass-assignment rewrites a ticket's status to "Resolved" without the proof gate; tampered audit log erases a wrongdoing trace; malicious upload alters stored MoM. |
SEC-026 (DTO whitelist validation), SEC-028 (parameterised queries), SEC-029 (upload AV + content-type + size), SEC-039 (append-only audit), SEC-041 (hash-chained tamper-evidence), SEC-043 (off-host audit copy). |
| Repudiation |
Staff member denies closing a VIP ticket or denies that a PII export occurred; vendor denies an outbound NADRA call leaked data. |
SEC-040 (who/what/when/why/trace_id), SEC-042 (read-audit on confidential/VIP), SEC-044 (audit retention ≥ 7 years), SEC-074 (centralised structured logs), NFR-OBS-007 (AI-call audit). |
| Information disclosure |
DB read compromise exposes plaintext CNIC; cloud LLM receives raw PII; a company rep sees another company's tickets; a presigned URL leaks. |
SEC-019 (field-level PII vault), SEC-018 (AES-256 at rest), SEC-048 (PII redaction before cloud AI), SEC-009 (ABAC confidential/VIP), SEC-008 (RBAC + row scoping), presigned URL expiry (/specs/en/15-tech-architecture/ §9). |
| Denial of service |
Flood of login/OTP or ticket-creation requests starves the API; a 100 MB upload per request exhausts disk; AI/OCR queue starves notifications. |
SEC-031 (WAF), SEC-032 (per-user/IP/tenant rate limits), SEC-033 (CAPTCHA/abuse), upload size caps, NFR-SCAL-002 (queue separation), NFR-AVAIL-003 (graceful degradation). |
| Elevation of privilege |
A Filer role escalates to Admin via a missing guard; a staff member reads outside their department; an IDOR lets a user read ?ticket_id= of another company; break-glass used without trace. |
SEC-008/SEC-009 (RBAC + ABAC), SEC-010 (least privilege), SEC-011 (break-glass logged), SEC-026 (no mass-assignment), SEC-067 (quarterly recertification), NFR-USA-002 (role-scoped dashboards). |
The diagram traces a representative inbound request through every trust boundary and shows which STRIDE class is addressed at each hop. The written description follows.
flowchart TD
U["User / Attacker<br/>(Internet)"]
EDGE["nginx Edge<br/>TLS · WAF · rate-limit"]
KC["Keycloak<br/>OIDC · 2FA · step-up"]
GW["NestJS API<br/>AuthZ guards · DTO validation · audit"]
DATA["Stateful backends<br/>MariaDB · Redis · MinIO · Meilisearch"]
PII["PII vault + AES-256 at rest"]
AUD["Append-only, hash-chained audit"]
EXT["External integrations<br/>NADRA · SECP · e-Office"]
AI["AI / OCR engines<br/>(cloud or on-prem)"]
RED["PII redaction layer"]
U -- "S (spoofing) · DoS · T (injection)" --> EDGE
EDGE -- "EoP · R (repudiation)" --> KC
KC -- "authenticated token" --> GW
GW -- "T · ID (info disclosure)" --> DATA
DATA <--> PII
GW -- "EoP · ID · R" --> EXT
GW -- "ID (PII egress)" --> RED
RED -- "redacted payload" --> AI
GW -- "every state change + sensitive read" --> AUD
GW -- "every read of Confidential/Restricted" --> AUD
classDef threat fill:#fdf2f0,stroke:#9b2c2c,color:#9b2c2c;
classDef control fill:#f0f6fd,stroke:#2c5282,color:#2c5282;
class U,EDGE,KC,GW,DATA,EXT,AI control;
class PII,AUD,RED control;
The flow shows the internet → edge hop as the primary ingress for spoofing, denial-of-service, and tampering (injection) threats, mitigated at the edge by TLS, the WAF, and rate limiting. The edge → Keycloak → API hops are where elevation-of-privilege and repudiation threats are stopped: Keycloak authenticates and applies 2FA / step-up, and the API's authorization guards resolve role and attribute before any data access. The API → backends and API → integrations hops are where tampering and information-disclosure threats are addressed — by parameterised queries, row-level scoping, field-level encryption, and circuit breakers on outbound calls. The API → AI/OCR hop is the principal PII-egress risk and is gated by the on-prem redaction layer before any cloud engine is invoked. Finally, every state change and every read of a confidential or restricted record is written to the append-only, hash-chained audit log, which is exported off-host — closing the repudiation threat across the whole system.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-001 |
A documented STRIDE threat model shall be maintained for SITP and reviewed at each phase gate and before any major architectural change. |
Must |
NFR-SEC-001 |
| SEC-002 |
Threat-model changes shall be reflected in this document and in the test strategy's abuse-case coverage (/specs/en/13-test-strategy/). |
Should |
NFR-SEC-007 |
Authentication is provided by a self-hosted Keycloak identity provider speaking OIDC to the NestJS API and the Next.js portal (see /specs/en/15-tech-architecture/ §10). Two realm classes exist: one for government staff (federated to the existing government identity provider where possible via OIDC SSO) and one for company representatives / citizens.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-003 |
The system shall use Keycloak as the sole OIDC identity provider for end users and staff; no service shall implement its own password store or token issuance. |
Must |
NFR-SEC-004 |
| SEC-004 |
Password policy shall enforce minimum length (≥ 12), complexity, breach-password denylist (e.g., HaveIBeenPwned-style check), rotation history, and progressive lockout after repeated failures. |
Must |
NFR-SEC-004, NFR-SEC-013 |
| SEC-005 |
2FA shall be mandatory for all government staff (TOTP authenticator primary; SMS OTP fallback where device support is limited); company representatives shall be offered 2FA opt-in. |
Must |
NFR-SEC-004 |
| SEC-006 |
Sensitive actions (closing a VIP/confidential ticket, deleting a record, exporting sensitive analytics, changing a Primary Authorized Rep, changing a feature flag, break-glass invocation) shall require step-up authentication: a fresh re-authentication ≤ 5 min, or a fresh 2FA challenge. |
Must |
NFR-SEC-005 |
| SEC-007 |
Account-takeover protection shall include: device/IP change challenge, anomalous-login alert, secure credential recovery (verified identity, time-delayed reset, revoke all sessions on recovery), and notification to the account's registered email/phone on password or 2FA change. |
Must |
NFR-SEC-004 |
| SEC-012 |
Government staff identity may be federated from the existing government IdP via OIDC SSO; federation claims shall be validated and mapped to SITP roles at each login. |
Should |
NFR-SEC-004 |
Note: control IDs are sequential across the whole document; this section intentionally skips 008–011 because those IDs belong to the Authorization section below.
Authorization is enforced at two layers (/specs/en/15-tech-architecture/ §10): the API layer (RolesGuard / PermissionsGuard) for coarse route-level access, and the data layer (Prisma query extensions / row-level scopes) so that even an authenticated staff member reads only the tickets their role and department entitle them to. For confidential and VIP tickets, an ABAC check extends RBAC: only explicitly listed watchers and the escalation chain can read.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-008 |
RBAC shall be enforced at the API layer (route guards) and at the data layer (row-level scoping); no endpoint shall expose data outside the caller's role and department. |
Must |
NFR-USA-002, NFR-SEC-001 |
| SEC-009 |
Confidential and VIP tickets shall be governed by ABAC: only explicitly listed watchers, the assigned staff, and the configured escalation chain (DG / Secretary / SACM) may read, comment, or act; all others shall be denied even within the same department. |
Must |
NFR-PRIV-003, NFR-AUD-004 |
| SEC-010 |
The principle of least privilege shall apply to every role and permission template; granular per-permission overrides (Primary/Admin/Filer/Viewer/Notify) shall default to deny. |
Must |
NFR-USA-002 |
| SEC-011 |
A break-glass emergency-access procedure shall exist (segregated account, step-up auth, time-boxed, auto-revoked) and every break-glass invocation shall be audit-logged and reviewed within one business day. |
Must |
NFR-SEC-005, NFR-AUD-004 |
| SEC-013 |
Permission templates, role definitions, and per-department overrides shall be versioned, change-controlled, and audited; changes require step-up auth and are recorded with before/after diff. |
Must |
NFR-AUD-001 |
The diagram shows the decision flow for an incoming API request, in the order the guards execute. The written description follows.
flowchart TD
REQ["Inbound request<br/>(OIDC access token)"]
AUTHN{"AuthGuard<br/>token valid?"}
STEP{"StepUpGuard<br/>sensitive action?"}
SU["Step-up challenge<br/>(re-auth ≤ 5 min / 2FA)"]
FFG{"FeatureFlagGuard<br/>route enabled?"}
ROLES{"RolesGuard<br/>role permitted?"}
PERM{"PermissionsGuard<br/>granular permission?"}
THRO{"ThrottlerGuard<br/>within rate limit?"}
BIZ{"ABAC check<br/>(confidential/VIP? watcher? dept?)"}
DATA["Row-level scoping<br/>(Prisma query extension)"]
ALLOW["Allow + audit write/read-audit"]
DENY["Deny (403) + audit"]
REQ --> AUTHN
AUTHN -- no --> DENY
AUTHN -- yes --> STEP
STEP -- yes, stale --> SU
STEP -- recent --> FFG
SU --> FFG
STEP -- no --> FFG
FFG -- off --> DENY
FFG -- on --> THRO
THRO -- over --> DENY
THRO -- ok --> ROLES
ROLES -- no --> DENY
ROLES -- yes --> PERM
PERM -- no --> DENY
PERM -- yes --> BIZ
BIZ -- denied --> DENY
BIZ -- allowed --> DATA
DATA --> ALLOW
A request arrives with an OIDC access token. The AuthGuard first verifies token validity and revocation status (checked against the Redis-mirrored denylist). If the action is on the sensitive-action list, the StepUpGuard checks that the session was recently re-authenticated; a stale session is challenged with step-up before the request proceeds. The FeatureFlagGuard short-circicts any route whose capability flag is off (features ship dark). The ThrottlerGuard enforces per-user/IP/tenant rate limits. The RolesGuard then resolves the coarse role, and the PermissionsGuard resolves the granular per-permission override. For confidential and VIP records, the ABAC check narrows access to the configured watchers and escalation chain; for all records the row-level scoping in the data layer ensures no query can read across companies, departments, or confidentiality boundaries. Allowed actions write an audit row; denied actions are also audited and surfaced as 403. Crucially, authorization is evaluated server-side on every request — the client never asserts scope.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-014 |
Access tokens shall be short-lived (≤ 15 min); refresh tokens ≤ 7 days with rotation on use and reuse-detection (rotated token reuse revokes the session family). |
Must |
NFR-SEC-013 |
| SEC-015 |
Token revocation (logout, admin force-logout, breach) shall propagate to the Redis denylist within ≤ 5 s and be honoured on the next request. |
Must |
NFR-SEC-013 |
| SEC-016 |
Idle session timeout shall be ≤ 30 min for the staff UI and ≤ 24 h for the citizen UI; an absolute session ceiling shall apply regardless of activity. |
Must |
NFR-SEC-013 |
| SEC-017 |
Logout shall destroy server-side session state, revoke tokens at Keycloak, and clear client-side stores; the SameSite and Secure cookie attributes shall be set on all session cookies. |
Must |
NFR-SEC-013 |
| SEC-018 |
CSRF protection shall be applied to all cookie-authenticated state-changing requests (double-submit token or synchroniser-token pattern); API-token clients are exempt (Authorization header). |
Must |
NFR-SEC-001 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-019 |
All external traffic shall use TLS 1.2+ (TLS 1.3 preferred); TLS 1.0/1.1 and legacy ciphers disabled; HSTS with max-age ≥ 31536000; includeSubDomains; preload; SSL Labs rating A or A+. Internal service-to-service traffic shall use TLS within the host network where feasible. |
Must |
NFR-SEC-002 |
| SEC-020 |
Data at rest shall be encrypted with AES-256 (or stronger): MariaDB (TDE or table-level), MinIO buckets (SSE), backups, Keycloak realm exports, and exported archives. |
Must |
NFR-SEC-003 |
| SEC-021 |
PII fields (CNIC, phone, email, home address, biometric-like data) shall be field-level encrypted or stored in a dedicated PII vault table with a reversible token in the host table; decryption shall be role-bound and audit-logged. |
Must |
NFR-PRIV-003 |
| SEC-022 |
Cryptographic keys shall be managed by the secrets vault / KMS (never embedded in images, repos, or runtime env files); envelope encryption shall be used for field-level PII. |
Must |
NFR-SEC-006 |
| SEC-023 |
Cryptographic keys shall be rotated on a documented schedule (data-encryption keys ≤ 12 months; transport certificates per CA guidance and on suspected compromise); rotation shall be non-disruptive. |
Must |
NFR-SEC-003 |
| SEC-024 |
Only approved, current cryptographic algorithms shall be used; MD5, SHA-1, RC4, DES, and 3DES are prohibited; password hashing shall use Argon2id (or bcrypt cost ≥ 12) at Keycloak. |
Must |
NFR-SEC-001 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-025 |
No DB password, API key, signing key, provider credential, or private certificate shall appear in source control, container images, build logs, or runtime env files on disk; all shall be fetched from the secrets vault (HashiCorp Vault or Server4Sale-managed) at startup. |
Must |
NFR-SEC-006 |
| SEC-026 |
Secrets shall be rotated on a documented schedule and on staff turnover / suspected compromise; rotation cadence and last-rotated date shall be tracked per secret. |
Must |
NFR-SEC-006 |
| SEC-027 |
A pre-commit and CI secret scanner (e.g., gitleaks / trufflehog) shall block any commit or build containing a high-entropy secret pattern; container images shall be scanned for embedded secrets. |
Must |
NFR-SEC-006 |
| SEC-028 |
Vault access shall be authenticated, role-bound, time-boxed, and audit-logged; quarterly vault-access reviews shall confirm no unauthorised retrieval. |
Should |
NFR-SEC-006 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-029 |
Every request body shall be validated against a class-validated DTO (class-validator + class-transformer) with whitelist + forbidNonWhitelisted; no raw any payload shall cross a controller boundary. |
Must |
NFR-SEC-001 |
| SEC-030 |
All database access shall use parameterised queries / the ORM parameter-binding API; string concatenation of user input into SQL is prohibited and lint-enforced. |
Must |
NFR-SEC-001 |
| SEC-031 |
Output encoding shall be contextual: HTML-escaping in server-rendered pages, React's automatic escaping in the portal, and explicit encoding in the (rare) dangerouslySetInnerHTML paths; no reflected user input rendered unescaped. |
Must |
NFR-SEC-001 |
| SEC-032 |
File uploads shall be validated by allowlist of MIME types and extensions, size cap per class, magic-byte verification, filename sanitisation, and ClamAV AV scan before release from quarantine; executable and macro-bearing types denied by default. |
Must |
NFR-SEC-012 |
| SEC-033 |
Outbound calls (integration adapters, AI/OCR engine calls) shall enforce SSRF protection: allowlist of destinations, no redirects to private ranges, no metadata-endpoint reachability; response size and timeout bounded. |
Must |
NFR-RELY-001 |
| Endpoint class |
Limit |
Scope |
| Login / OTP |
≤ 10 / min |
per IP |
| Password reset / 2FA retry |
≤ 5 / min |
per IP + per account |
| Ticket creation |
≤ 30 / min |
per user |
| AI / OCR endpoints |
≤ 20 / min |
per user |
| Search |
≤ 60 / min |
per user |
| Public (unauthenticated) read |
≤ 120 / min |
per IP |
| File upload |
≤ 10 / min |
per user |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-034 |
nginx shall run a WAF with the OWASP Core Rule Set in front of the API and portal; default-deny on criticals; tuning exceptions reviewed monthly; ModSecurity audit log retained 90 days. |
Must |
NFR-SEC-008 |
| SEC-035 |
Rate limits shall be applied per user, per IP, and per tenant at the values above; nginx limit-req at the edge and @nestjs/throttler (Redis-backed) at the API; a throttle firing > 1,000×/min alerts on-call (potential abuse). |
Must |
NFR-SEC-009 |
| SEC-036 |
CAPTCHA and adaptive abuse detection shall be applied to abuse-prone endpoints (login, registration, public ticket filing, anonymous/whistleblower intake); repeat offenders are temporarily blocked. |
Should |
NFR-USA-005 |
| Header |
Value |
Content-Security-Policy |
Strict, per-route; default-src 'self'; no unsafe-inline for scripts; nonces for whitelisted inline; connect-src limited to the API + analytics endpoint |
Strict-Transport-Security |
max-age=31536000; includeSubDomains; preload |
X-Content-Type-Options |
nosniff |
X-Frame-Options |
DENY (or CSP frame-ancestors 'none') |
Referrer-Policy |
strict-origin-when-cross-origin |
Permissions-Policy |
Restrictive defaults (no camera, mic, geolocation, payment unless needed) |
Cache-Control |
no-store on authenticated, PII-bearing, and API responses |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-037 |
All responses shall set the security headers above; Mozilla Observatory target A or higher; header presence checked in CI per release. |
Must |
NFR-SEC-010 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-038 |
All dependencies (npm, pip, container base images) shall be scanned for known vulnerabilities (SCA) on every build and nightly; critical CVEs (CVSS ≥ 9.0) in production dependencies remediated within 7 days, high (7.0–8.9) within 30 days; an open-findings dashboard by severity and age shall be maintained. |
Must |
NFR-SEC-011 |
| SEC-039 |
A Software Bill of Materials (SBOM) shall be generated per release (CycloneDX), stored with the artefact, and retained; the SBOM is the basis for vulnerability matching and supply-chain attestation. |
Must |
NFR-SEC-011 |
| SEC-040 |
Container images shall be scanned (e.g., Trivy) on build; images with critical vulnerabilities shall not be promoted to production; base images pinned to digests, not mutable tags. |
Must |
NFR-SEC-011 |
| SEC-041 |
Infrastructure-as-Code (Compose, future Kubernetes manifests, nginx config) and IaC secrets shall be scanned on change; open-source licence compliance checked per dependency. |
Should |
NFR-SEC-011 |
SITP shall satisfy OWASP Application Security Verification Standard (ASVS) Level 2 in full before production go-live (NFR-SEC-001). The table maps the principal ASVS v4 chapters to the SITP controls that satisfy them; the independent assessor's L2 checklist is the authoritative verification artefact.
| ASVS v4 chapter |
Title |
Satisfied by SITP controls |
| V1 |
Architecture, Threat Modeling, Reference Architecture |
SEC-001, SEC-002, /specs/en/15-tech-architecture/ §16 |
| V2 |
Authentication |
SEC-003, SEC-004, SEC-005, SEC-007, SEC-012 |
| V3 |
Session Management |
SEC-014, SEC-015, SEC-016, SEC-017, SEC-018 |
| V4 |
Access Control |
SEC-008, SEC-009, SEC-010, SEC-011, SEC-013 |
| V5 |
Validation, Sanitization & Encoding |
SEC-029, SEC-030, SEC-031, SEC-032 |
| V6 |
Stored Cryptography |
SEC-020, SEC-021, SEC-024 |
| V7 |
Error Handling & Logging |
SEC-039–SEC-044 (audit), /specs/en/03-non-functional-reqs/ NFR-OBS-001 |
| V8 |
Data Protection |
SEC-021, SEC-045–SEC-051 (privacy), NFR-PRIV-006 |
| V9 |
Communications |
SEC-019, SEC-033 (SSRF) |
| V10 |
Malicious Code |
SEC-027, SEC-032, SEC-038–SEC-040 |
| V11 |
Business Logic |
SEC-009 (ABAC), SEC-006 (step-up), resolution-proof gate (_context.md §5) |
| V12 |
Files & Resources |
SEC-032, /specs/en/15-tech-architecture/ §9 |
| V13 |
API & Web Service |
SEC-029, SEC-033, /specs/en/12-api-contract/ |
| V14 |
Configuration |
SEC-025, SEC-037, /specs/en/15-tech-architecture/ §17 |
The audit log is the universal currency of government accountability. Every state-changing action and every read of a confidential/restricted record is captured in the append-only aud_event table (see /specs/en/05-data-model/ and /specs/en/15-tech-architecture/ §10, §16).
| ID |
Control |
[M|S|C] |
Trace |
| SEC-042 |
The audit log (aud_event) shall be append-only: no database role shall hold UPDATE or DELETE privileges on it; monthly partitions; inserts only. |
Must |
NFR-COMP-003, NFR-AUD-001 |
| SEC-043 |
Every audit row shall record the four-W + trace: who (user id + role + source IP), what (action + entity + before/after diff), when (UTC timestamp), why (business reason where applicable), and trace_id (for end-to-end correlation). |
Must |
NFR-AUD-001 |
| SEC-044 |
Audit rows shall be hash-chained (each row's hash incorporates the prior row's hash); tampering is therefore detectable; a quarterly verification job confirms the chain and pages on-call on any break. |
Must |
NFR-AUD-002 |
| SEC-045 |
Every read of a Confidential or Restricted record (ticket, file, MoM, PII vault entry) shall be audit-logged — not just writes — and abnormal read patterns shall raise a curiosity-reading alert. |
Must |
NFR-AUD-004 |
| SEC-046 |
The audit log shall be exported to off-host storage continuously or daily; the off-host copy retains the hash chain and survives a host compromise. |
Must |
NFR-COMP-003 |
| SEC-047 |
The audit log shall be retained for ≥ 7 years (or longer per Sindh Archives rules — see §16); expired partitions move to long-term archival, never silently deleted. |
Must |
NFR-COMP-003, NFR-PRIV-007 |
SITP processes personal data of company representatives and government staff, plus sovereign data (CNIC, NADRA payloads). Privacy obligations follow the Sindh Transparency & Right to Information Act 2016 (which governs access to public information — see §18) and general data-protection principles (lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity, accountability). See /specs/en/03-non-functional-reqs/ §3.5.
| Class |
Definition |
Examples |
Handling |
| Public |
Approved for public release |
Public KB articles, transparency dashboard aggregates |
No restriction; CDN-cacheable |
| Internal |
For staff / internal operations |
Internal SOPs, department metrics |
Authenticated staff; not for public |
| Confidential |
Sensitive personal or business data |
Ticket content, MoM, company financials, contact details |
Field-level encryption; role + need-to-know; read-audited |
| Restricted |
Sovereign / high-harm data |
Raw CNIC, NADRA payloads, VIP tickets, biometric-like data, passwords/keys |
PII vault; ABAC; on-prem processing only; never to cloud AI |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-048 |
Every table and every API field shall be tagged with one of the four data classes; the class drives encryption, access, redaction, retention, and AI-engine selection; CI shall refuse a migration adding an untagged text/JSON column in a PII-bearing table. |
Must |
NFR-PRIV-005 |
| SEC-049 |
Data minimisation: each form and API payload shall collect only fields justified by a documented purpose; "nice-to-have" fields are removed unless justified at design review. |
Must |
NFR-PRIV-001 |
| SEC-050 |
Every user shall have a consent and preference record (channel opt-ins email/SMS/WhatsApp/in-app, marketing-vs-transactional, language) that is withdrawable in one click per channel; consent changes are audit-logged. |
Must |
NFR-PRIV-002 |
| SEC-051 |
Before any payload is sent to a cloud AI/OCR engine, PII shall be redacted by the on-prem redaction layer; the selector shall forbid cloud engines for Restricted data classes (raw CNIC, NADRA payloads, confidential/VIP tickets); on-prem fallback (Llama/Qwen + Tesseract) is used instead. |
Must |
NFR-PRIV-006, /specs/en/15-tech-architecture/ §6.2, §6.4 |
| SEC-052 |
A user may request erasure of their personal data; the system shall action within 30 days, except where data is subject to a legal retention obligation (audit log, tax records, ongoing-ticket evidence, Sindh Archives rules) — in which case the data shall be minimised/anonymised and the exception recorded. |
Should |
NFR-PRIV-004 |
| SEC-053 |
All production personal data and sovereign-data payloads shall reside on infrastructure within Pakistan (Server4Sale); cross-border transfer is permitted only for aggregated, anonymised, or PII-redacted payloads and only to providers with documented data-processing terms. |
Must |
NFR-PRIV-008 |
| SEC-054 |
A Data Protection Impact Assessment (DPIA) shall be on file before go-live and refreshed annually, covering PII flows, sovereign data, AI processing, and cross-border transfers. |
Must |
NFR-COMP-002 |
The retention schedule bounds data-at-risk and aligns with the records-management obligations in §17. Expired data is purged or archived by a scheduled worker; presigned URLs expire in ≤ 15 min; soft-deleted records are hard-purged after the class window unless subject to a legal hold.
| Data type |
Data class |
Retention period |
End-of-life action |
Authority |
| Tickets (resolved/closed) |
Confidential |
7 years after closure, then archive |
Archive → long-term storage; purge working copy after archive verified |
Sindh Archives rules; NFR-PRIV-007 |
| Tickets (open / under appeal) |
Confidential |
Until final closure + appeal window |
Hold; then enter the resolved schedule |
RTI Act 2016 (appeals) |
| RTI-category tickets |
Confidential |
20 years after closure, then review |
Archive; review for further retention |
Sindh Archives rules; RTI Act 2016 |
Audit log (aud_event) |
Restricted (meta) |
≥ 7 years, extend per Sindh Archives |
Off-host copy retained; partition archived not deleted |
NFR-COMP-003 |
| Uploaded attachments & MoMs |
Confidential |
Same as parent ticket |
Archive with parent; revoke presigned URLs immediately on closure |
Records management |
| PII vault entries (CNIC, contact) |
Restricted |
Life of the relationship + 3 years |
Anonymise / purge unless under retention hold |
Data minimisation |
| Consent / preference records |
Internal |
Life of relationship + 3 years |
Purge |
NFR-PRIV-002 |
| AI/OCR call audit rows |
Internal |
2 years |
Purge |
NFR-OBS-007 |
Integration call records (int_call) |
Internal |
3 years |
Purge |
NFR-INTER |
| Backups (logical / physical) |
Restricted (encrypted) |
30 days rolling + quarterly snapshots |
Overwrite / delete after rotation |
NFR-AVAIL-004 |
| MinIO object versions |
Confidential |
90 days of prior versions |
Expire via bucket lifecycle |
NFR-PRIV-007 |
| Keycloak realm export |
Restricted |
Per backup rotation (≤ 30 days rolling) |
Overwrite |
NFR-SEC-003 |
| Logs (Loki) |
Internal |
90 days hot; 1 year cold |
Age out |
NFR-OBS-001 |
| Session / token denylist (Redis) |
Internal |
Token lifetime |
Auto-expire |
NFR-SEC-013 |
| Abandoned draft tickets |
Confidential |
30 days |
Auto-delete |
NFR-PRIV-007 |
| Inactive user accounts |
Internal |
2 years inactivity → disabled; +3 years → anonymised |
Disable then anonymise |
Access reviews |
| Whistleblower / anonymous intake |
Restricted |
10 years (extended, identity-protected) |
Archive |
Trust & safety |
| Generated letters / certificates |
Confidential |
Same as parent ticket |
Archive with parent |
Records management |
Legal hold override: when a record is subject to litigation, audit, or RTI hold, the retention period is suspended and the record is preserved until the hold is lifted by the records officer. Holds are themselves audit-logged.
Government records carry statutory retention that overrides generic data minimisation. SITP aligns its records lifecycle with the Sindh Archives rules and with the national records-management convention (see _context.md §6).
| ID |
Control |
[M|S|C] |
Trace |
| SEC-055 |
A documented records-management procedure shall define what constitutes a record (tickets, MoMs, letters, resolution certificates, RTI requests, audit extracts), its class, its retention, and its archival path. |
Must |
NFR-COMP-004 |
| SEC-056 |
An archival workflow shall move expired records to long-term storage with index preservation (searchable by ticket ID, date, department, requester, subject); the archive is encrypted, versioned, and replicated off-host; the working copy is purged only after archive verification. |
Must |
NFR-COMP-004 |
| SEC-057 |
Disposal of records past retention shall be a documented, approved action (records officer + data owner) recorded in the audit log; no automatic mass-deletion outside the published schedule except for legal-hold exceptions. |
Must |
NFR-COMP-004 |
| SEC-058 |
Ticket and MoM records shall be pushable to the NITB e-Office for official file movement (/specs/en/08-integrations-spec/); the e-Office linkage preserves the government's authoritative record trail. |
Should |
NFR-INTER-003 |
| SEC-059 |
An annual archival audit shall verify that records were archived, indexed, and disposed of per schedule; findings tracked to closure. |
Must |
NFR-COMP-004 |
The Sindh Transparency & Right to Information Act 2016 gives citizens a statutory right to request information from public bodies and imposes statutory deadlines. SITP treats RTI as a first-class ticket category with its own SLA calendar, routing, and disclosure reporting (see _context.md §6, NFR-COMP-001).
| Stage |
Statutory timer (working days) |
Owner |
| PIO acknowledgement / response to RTI request |
10 working days (extendable by +10 for voluminous / third-party consultation) |
Public Information Officer (department) |
| First appeal (to head of public body) |
Filed within 30 days of response (or deemed refusal); decided within 30 days |
Head of public body |
| Second appeal (to Sindh Information Commission) |
Filed within 30 days of first-appeal decision |
Sindh Information Commission |
| Deemed refusal |
If no response within the statutory window, request is treated as refused → appeal right triggers |
— |
Confirm against Act text. Section numbers and exact day-counts above reflect the Sindh Transparency of Information Act 2016 as commonly cited; the records officer shall confirm the exact provisions before baseline freeze and cite the section in the SLA configuration.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-060 |
RTI shall be a special ticket category in the ticketing core, with its own routing, escalation, and a distinct SLA calendar aligned to the statutory timers above (10 working days, extendable). |
Must |
NFR-COMP-001 |
| SEC-061 |
The SLA engine shall apply the RTI calendar automatically — including the appeal windows, deemed-refusal detection, and Sindh public-holiday / weekend pausing (_context.md §5) — and shall alert before statutory deadlines are breached. |
Must |
NFR-COMP-001 |
| SEC-062 |
RTI compliance rates (on-time response %, deemed-refusal count, appeal outcomes) shall be reported on the public transparency dashboard and in the periodic RTI report to the Sindh Information Commission. |
Must |
NFR-COMP-001 |
| SEC-063 |
Pro-active / suo-moto disclosure of categories designated under the Act shall be supported via the public KB / circulars channel, reducing the need for reactive RTI requests. |
Should |
NFR-COMP-001 |
| SEC-064 |
Exemptions under the Act (information that may be withheld) shall be applied by an authorised officer with a recorded reason; exemption decisions are audit-logged and appealable. |
Must |
NFR-COMP-001 |
SITP is treated as Critical Information Infrastructure under Pakistan's framework and follows the national incident-response expectations (see _context.md §6, NFR-COMP-005).
| ID |
Control |
[M|S|C] |
Trace |
| SEC-065 |
An independent external penetration test shall be completed before public go-live; at least annually thereafter; and after any security-sensitive change. Critical findings remediated within 30 days, high within 60 days; report on file with a finding tracker. |
Must |
NFR-SEC-007 |
| SEC-066 |
A vulnerability management programme shall run continuously: SCA (§12), image scanning, infrastructure scanning, and authenticated web-app scanning on a recurring cadence; findings triaged by severity with SLA. |
Must |
NFR-SEC-011 |
| SEC-067 |
SITP shall be registered as Critical Information Infrastructure (CII) under Pakistan's framework; the registration certificate shall be on file; controls above support the CII posture. |
Should |
NFR-COMP-005 |
| SEC-068 |
CERT-PK coordination shall be maintained: a documented contact and escalation path, alignment of incident response with CERT-PK notification expectations, and participation in CERT advisories. |
Must |
NFR-COMP-005 |
| SEC-069 |
An Incident Response (IR) plan shall exist and cover: roles (incident commander, comms, forensics, legal), severity classification, containment / eradication / recovery steps, evidence preservation, and communication templates. |
Must |
NFR-COMP-005 |
| SEC-070 |
Tabletop exercises shall be run at least annually to rehearse the IR plan against representative scenarios (ransomware, credential compromise, PII exfiltration, insider misuse). |
Should |
NFR-COMP-005 |
| SEC-071 |
A responsible-vulnerability-disclosure channel (security contact, PGP key, acknowledgement SLA) shall be published; inbound reports triaged and remediated per severity. |
Should |
NFR-SEC-007 |
The portal must be audit-ready on demand for the Auditor-General (AG), the Public Accounts Committee (PAC), internal audit, and dispute resolution. The audit log (§14) and records (§17) are the primary evidence.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-072 |
The audit log shall be exportable (CSV/Excel/JSON) over a selectable date range and action filter, scoped to the requesting auditor's authority, with a signed manifest; the export itself is audit-logged. |
Must |
NFR-AUD-003 |
| SEC-073 |
Ticket and MoM records shall be linkable to the e-Office file movement so an auditor can trace a decision from portal → official file → outcome. |
Should |
NFR-INTER-003, NFR-COMP-004 |
| SEC-074 |
Where PPP service fees are levied, the financial flow (invoicing, collection, reconciliation) shall be auditable and transparent; financial records follow the tax-records retention in §16. |
Should |
NFR-COMP-006, /specs/en/23-ppp-vendor-exit/ |
| SEC-075 |
Source-code escrow and the PPP exit/handover plan shall be in place so the Government of Sindh retains continuity and auditability across vendor change. |
Must |
NFR-COMP-006, /specs/en/23-ppp-vendor-exit/ |
| SEC-076 |
Evidence packs (pen-test reports, ASVS assessment, DPIA, CII registration, IR plan, access-review records) shall be maintained and produced on request for AG/PAC audit cycles. |
Must |
NFR-COMP-003, NFR-AUD-003 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-077 |
Quarterly access recertification: every staff account, role assignment, granular permission override, and break-glass entitlement shall be reviewed and re-approved by the relevant department head; lapsed entitlements are revoked. |
Must |
NFR-SEC-004, NFR-AUD-001 |
| SEC-078 |
A joiner-mover-leaver process shall provision, modify, and deprovision access in sync with HR events; leavers are disabled within one business day and sessions revoked. |
Must |
NFR-SEC-004 |
| SEC-079 |
Privileged-access reviews (DBAs, Super Admins, break-glass holders, vault admins) shall occur at least quarterly with a stricter evidence threshold; privileged sessions are recorded where feasible. |
Must |
NFR-SEC-005 |
| SEC-080 |
A weekly compliance report shall list any staff account without 2FA enrolled and any account with access outside its department scope. |
Must |
NFR-SEC-004 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-081 |
A secure-coding standard (based on OWASP ASVS / OWASP Proactive Controls) shall be published and followed; security-relevant code review checklist applied on every pull request. |
Must |
NFR-MAINT-003 |
| SEC-082 |
No code shall reach main without (a) ≥ 1 approving review, (b) green lint, (c) green typecheck, (d) green unit tests, (e) green SCA, (f) green secret scan; branch protection enforces all six. |
Must |
NFR-MAINT-003, NFR-SEC-006 |
| SEC-083 |
CI/CD security gates shall run on every build: SCA, secret scan, image scan, IaC scan, licence check, header check, and (on staging) the OWASP ZAP baseline scan; a failing gate blocks promotion. |
Must |
NFR-SEC-011 |
| SEC-084 |
Threat modeling shall be performed for new features touching authentication, authorization, payments, PII, or integrations; the threat-model section (§3) is updated with the findings. |
Should |
NFR-SEC-001 |
| SEC-085 |
Security training shall be provided to all engineers on induction and annually thereafter (OWASP Top 10, secure coding, incident reporting). |
Should |
NFR-MAINT-003 |
| SEC-086 |
Production access from CI/CD shall use short-lived, vault-issued credentials with least privilege; long-lived deploy keys are prohibited; deploys to staging and prod require manual approval gates. |
Must |
NFR-SEC-006 |
Observability is wired from day one (/specs/en/15-tech-architecture/ §18). Security-relevant monitoring extends that baseline.
| ID |
Control |
[M|S|C] |
Trace |
| SEC-087 |
All services shall emit structured JSON logs to Loki carrying trace_id, user_id, module, level, timestamp; PII shall never be logged (redaction enforced and tested). |
Must |
NFR-OBS-001 |
| SEC-088 |
SIEM integration hooks shall be provided so security-relevant events (auth failures, step-up, break-glass, ABAC denials, WAF criticals, rate-limit storms, read-audit anomalies, AI redaction failures) can be forwarded to a SIEM / log-analysis platform for correlation and retention beyond Loki's window. |
Must |
NFR-OBS-002 |
| SEC-089 |
Alerting shall page on-call for: brute-force login, break-glass use, mass-ABAC-denial, WAF critical, audit hash-chain break, PII-in-logs detection, and breach indicators; alert noise reviewed monthly (target > 90 % actionable). |
Must |
NFR-OBS-004 |
| SEC-090 |
Anomaly / behavioural baselines shall be maintained for privileged-account activity, PII-vault decrypt volume, and after-hours sensitive reads; deviations raise alerts for review. |
Should |
NFR-AUD-004 |
| SEC-091 |
The public status page shall report security-relevant outages (auth, WAF) honestly and within 15 min of declaration, consistent with NFR-OBS-005. |
Must |
NFR-OBS-005 |
| ID |
Control |
[M|S|C] |
Trace |
| SEC-092 |
A breach notification process shall define: what constitutes a reportable incident (confirmed unauthorised access to / exfiltration of personal or sovereign data), severity classification, internal escalation, CERT-PK notification within 24 hours of a reportable incident, and notification to affected individuals and the Sindh Information Commission where required. |
Must |
NFR-COMP-005 |
| SEC-093 |
Forensic readiness shall be maintained: audit logs + off-host copies preserved, evidence-preservation procedure on incident declaration, chain-of-custody for evidence, and an IR team trained to collect and hand off evidence. |
Must |
NFR-COMP-005, NFR-AUD-002 |
| SEC-094 |
Post-incident review (blameless postmortem) shall be conducted for every P0/P1 incident within 10 business days, with root cause, timeline, and remediation actions tracked to closure; lessons feed back into §3 (threat model) and §22 (SSDLC). |
Must |
NFR-COMP-005 |
| SEC-095 |
A communications playbook shall govern internal, inter-departmental, public, and media communications during a breach, with pre-approved templates aligned to government comms norms. |
Should |
NFR-COMP-005 |
| Domain |
Controls |
IDs |
Count |
TM |
Threat modeling |
SEC-001 – SEC-002 |
2 |
AUTHN |
Authentication |
SEC-003 – SEC-007, SEC-012 |
6 |
AUTHZ |
Authorization |
SEC-008 – SEC-011, SEC-013 |
5 |
SESS |
Session management |
SEC-014 – SEC-018 |
5 |
CRYPTO |
Cryptography |
SEC-019 – SEC-024 |
6 |
SECRET |
Secrets management |
SEC-025 – SEC-028 |
4 |
IVOE |
Input validation & output encoding |
SEC-029 – SEC-033 |
5 |
WAF |
WAF, rate limiting, abuse |
SEC-034 – SEC-036 |
3 |
HDR |
Secure headers |
SEC-037 |
1 |
SCA |
Dependency / SBOM / scanning |
SEC-038 – SEC-041 |
4 |
AUD |
Audit logging |
SEC-042 – SEC-047 |
6 |
PRIV |
Data protection & privacy |
SEC-048 – SEC-054 |
7 |
REC |
Records management & archival |
SEC-055 – SEC-059 |
5 |
RTI |
Sindh RTI Act 2016 |
SEC-060 – SEC-064 |
5 |
POST |
Cybersecurity posture |
SEC-065 – SEC-071 |
7 |
GAUD |
Government audit readiness |
SEC-072 – SEC-076 |
5 |
AR |
Access reviews & recertification |
SEC-077 – SEC-080 |
4 |
SSDLC |
Secure SDLC & CI/CD |
SEC-081 – SEC-086 |
6 |
MON |
Logging / monitoring / SIEM |
SEC-087 – SEC-091 |
5 |
BR |
Breach notification & forensics |
SEC-092 – SEC-095 |
4 |
| Total |
— |
SEC-001 – SEC-095 |
95 |
| Priority |
Count |
| Must |
81 |
| Should |
14 |
| Could |
0 |
| Won't (this phase) |
0 |
| Total |
95 |
| Item |
Owner |
Decision needed by |
| Exact section numbers and day-counts under the Sindh Transparency & RTI Act 2016 (§18.1) — records officer to cite the provisions in the SLA configuration. |
S&ITD records officer |
Phase-1 gate |
| Choice of secrets vault (HashiCorp Vault vs Server4Sale-managed) and final key-rotation cadence (SEC-023, SEC-026). |
MAAHIR + Server4Sale |
Phase-1 gate |
| CII registration timeline and the certifying authority (SEC-067). |
S&ITD Secretary |
Phase-3 gate |
Confirmed RPO/RTO numbers feeding breach-impact assessment (links /specs/en/15-tech-architecture/ §21). |
MAAHIR ops |
First production month |
| SIEM platform selection for forward-and-correlate (SEC-088) — Loki-only initially, external SIEM when the CII posture requires it. |
MAAHIR + S&ITD |
Phase-3 gate |
| Detailed hosting topology / network zoning on Server4Sale affecting WAF placement and internal TLS (SEC-019, SEC-034). |
MAAHIR + Server4Sale |
Phase-1 gate |
| Break-glass account inventory and approving authorities (SEC-011). |
S&ITD Secretary |
Phase-1 gate |
These [TBD/confirm] items are tracked to closure in /specs/en/14-roadmap-release/ and reflected back into this document as the decisions land.
End of document.