W-12: Security Operations Ways of Work¶
| Field | Value |
|---|---|
| Document | W-12 |
| Title | Security Operations Ways of Work |
| Status | Draft |
| Owner | CISO (Danish Hamid) |
| Created | 2026-04-05 |
| Review | Quarterly |
| Depends On | W-01 (Company Operating Rhythm), W-10 (Engineering Ways of Work), STD-SECURITY-041 (Incident Classification), STD-SECURITY-042 (Penetration Testing), STD-SECURITY-043 (Bug Bounty Programme), STD-SECURITY-044 (Data Breach Response), Incident Response Playbook |
Purpose¶
Define how Simpaisa's security organisation operates day-to-day: how we detect threats, respond to incidents, manage vulnerabilities, and maintain compliance across all seven markets. This is the single source of truth for security operations process. If it is not in this document, it is not how the security team works.
This document applies to the entire security function reporting to the CISO, covering SOC, NOC, and InfoSec operations.
Team Structure¶
CISO — Danish Hamid
├── NOC (Network Operations Centre)
│ └── Rohit Rana (NOC Lead)
│ ├── 2 × NOC Engineers (24/7 monitoring rotation)
│ └── 1 × NOC Analyst
│
├── SOC (Security Operations Centre)
│ └── Rana Khubaib (SOC Lead)
│ ├── 2 × SOC Analysts (alert triage, threat detection)
│ └── 1 × Incident Response Analyst
│
└── Information Security
└── Hamza Bari (InfoSec Manager)
├── 1 × Security Engineer (tooling, automation)
├── 1 × Compliance Analyst (audit support, policy)
└── 1 × Application Security Analyst (code review, pen test coordination)
Reporting: All security leads report to the CISO. The CISO reports to the CDO. Security operations provide cross-cutting services to all engineering teams and the wider business.
1. SOC Daily Operations¶
Alert Triage¶
The SOC operates a continuous monitoring model. Every alert is triaged within the SLA defined by its source severity.
| Alert Source | Examples | Triage SLA | Escalation Path |
|---|---|---|---|
| WAF (CloudFront / AWS WAF) | Blocked requests, rate-limit triggers, geo-blocking events | 15 minutes | SOC Analyst → SOC Lead → CISO |
| CloudWatch Alarms | CPU spikes, memory exhaustion, error rate thresholds | 15 minutes | SOC Analyst → DevOps on-call |
| Snyk (runtime) | Critical vulnerability in running container | 30 minutes | SOC Analyst → Engineering team lead |
| SonarQube | Critical security hotspot in merged code | 4 hours | InfoSec → Engineering team lead |
| GuardDuty / CloudTrail | Unusual API calls, IAM anomalies, credential exposure | 15 minutes | SOC Analyst → SOC Lead → CISO |
| Partner / Channel alerts | Settlement failures, API errors from partner side | 30 minutes | NOC Analyst → Operations team |
Incident Classification¶
All security incidents are classified per STD-SECURITY-041:
| Severity | Definition | Response Time | Example |
|---|---|---|---|
| SEV-1 (Critical) | Active data breach, service compromise, credential exposure affecting production | Immediate (within 15 min) | Database credentials leaked, active intrusion detected |
| SEV-2 (High) | Exploitable vulnerability in production, failed authentication anomaly at scale | Within 1 hour | SQL injection attempt succeeding, brute-force attack on merchant portal |
| SEV-3 (Medium) | Vulnerability identified but not yet exploited, policy violation | Within 4 hours | Unpatched critical CVE on non-internet-facing service |
| SEV-4 (Low) | Informational finding, minor policy deviation | Within 24 hours | Expired TLS certificate on internal tooling |
Daily SOC Review¶
When: Daily, 09:30 local time (per W-01) Duration: 15 minutes (hard stop) Attendees: SOC team + NOC on-call representative Agenda: 1. Overnight alert summary (2 min) 2. Open incidents status (5 min) 3. Threat intelligence updates (3 min) 4. Handover items from NOC (3 min) 5. Action items (2 min)
Output: Daily SOC log entry in the security incident tracker.
2. Vulnerability Scanning¶
Continuous Scanning (CI/CD Pipeline)¶
Snyk is integrated into every Bitbucket CI pipeline. No code merges to main or develop without passing Snyk checks.
| Scan Type | Tool | When | Blocking? | Owner |
|---|---|---|---|---|
| Dependency scan (SCA) | Snyk | Every PR, every merge to main | Yes — critical and high block merge | Engineering teams |
| Container image scan | Snyk Container | Every Docker build in CI | Yes — critical blocks deployment | DevOps team |
| Static analysis (SAST) | SonarQube | Every PR | Yes — critical security hotspots block merge | Engineering teams |
| Infrastructure as Code | Snyk IaC | Every Terraform PR | Yes — high and critical block merge | DevOps team |
| Licence compliance | Snyk | Every PR | Advisory (logged, not blocking) | InfoSec |
Snyk severity thresholds: - Critical: Must be remediated before merge. No exceptions. - High: Must be remediated before merge, or an exception granted by the CISO with a remediation deadline (max 14 days). - Medium: Tracked in backlog. Must be resolved within current quarter. - Low: Tracked. Resolved opportunistically.
Periodic External Scanning¶
| Scan | Frequency | Scope | Performed By | Report To |
|---|---|---|---|---|
| External vulnerability scan | Monthly | All internet-facing endpoints, APIs, merchant portal | InfoSec (using approved scanning tool) | CISO → CDO |
| PCI ASV scan (where applicable) | Quarterly | Payment-processing infrastructure | Approved Scanning Vendor | CISO → CFO → Auditor |
| Cloud configuration review | Monthly | All AWS accounts (production, staging, DR) | DevOps + InfoSec | CISO |
| DNS and certificate audit | Monthly | All Simpaisa domains, TLS certificates | InfoSec | CISO |
Vulnerability Remediation SLAs¶
| Severity | Internet-Facing | Internal | Evidence Required |
|---|---|---|---|
| Critical | 48 hours | 7 days | Patch deployed + re-scan clean |
| High | 7 days | 14 days | Patch deployed + re-scan clean |
| Medium | 30 days | 60 days | Ticket closed with verification |
| Low | 90 days | Next scheduled maintenance | Ticket closed |
If a remediation SLA cannot be met, the responsible team lead must request an exception from the CISO with a documented remediation plan and revised deadline.
3. Penetration Testing¶
Per STD-SECURITY-042, Simpaisa conducts both internal and external penetration testing.
| Test Type | Frequency | Scope | Performed By | Report To |
|---|---|---|---|---|
| External penetration test | Annually (July, per W-01 annual calendar) | All internet-facing services, APIs, merchant portal, mobile SDKs | External firm (rotated every 2 years) | CISO → CDO → Technology & InfoSec Board Committee |
| Internal penetration test | Annually (offset by 6 months from external) | Internal network, lateral movement, privilege escalation | External firm or qualified internal resource | CISO → CDO |
| Application-specific pen test | Per major release (new payment corridor, new API version) | Target application / API | InfoSec team or external firm | CISO → CTO |
| Red team exercise | Every 2 years | Full organisation (social engineering, phishing, physical) | External specialist firm | CISO → CDO → CEO |
Penetration test process: 1. CISO defines scope and rules of engagement. 2. Testing window agreed (minimum 2 weeks for external, 1 week for application-specific). 3. NOC and SOC are informed (but not given specifics — tests should validate detection capability). 4. Findings report delivered within 10 business days of test completion. 5. CISO reviews and classifies findings by severity. 6. Remediation plan created within 5 business days of report delivery. 7. Re-test of critical and high findings within 30 days of remediation. 8. Final report (including remediation evidence) archived and presented to CDO.
4. Bug Bounty Programme¶
Per STD-SECURITY-043, Simpaisa operates a managed bug bounty programme.
Platform: Managed via an approved bug bounty platform (e.g. HackerOne, Bugcrowd, or equivalent regional provider).
Scope: - In scope: Merchant portal, public APIs, mobile SDKs, payment pages. - Out of scope: Corporate website (informational only), internal tools, third-party services.
Reward tiers:
| Severity | Reward Range (USD) | Examples |
|---|---|---|
| Critical | $1,000 – $5,000 | Remote code execution, authentication bypass, payment manipulation |
| High | $500 – $1,000 | Stored XSS on payment page, IDOR exposing merchant data |
| Medium | $100 – $500 | Reflected XSS, information disclosure of non-sensitive data |
| Low | $50 – $100 | Missing security headers, verbose error messages |
Process: 1. Researcher submits finding via platform. 2. InfoSec triages within 2 business days. 3. Valid findings assigned a severity and forwarded to the responsible engineering team. 4. Remediation follows the same SLAs as vulnerability scanning findings. 5. Researcher notified of acceptance/rejection within 5 business days. 6. Payment processed within 30 days of verified fix. 7. CISO reviews all bug bounty activity monthly.
Rules: - No bounties paid for findings already known from internal scanning. - Duplicate reports receive a "thank you" acknowledgement but no reward. - All bounty expenditure approved by CISO, reported to CDO monthly.
5. Security Review Triggers¶
The following changes require a security review before deployment to production. The review is conducted by InfoSec (Hamza Bari's team) and, for significant items, escalated to the CISO.
| Trigger | Review Type | Reviewer | Turnaround |
|---|---|---|---|
| New public API endpoint | Threat model + code review | InfoSec + SOC Lead | 3 business days |
| Changes to authentication or authorisation logic | Threat model + code review | InfoSec + CISO | 3 business days |
| New handling of PII or sensitive data fields | Data classification review + code review | InfoSec + Data Lead | 3 business days |
| New third-party integration (SDK, API, partner) | Vendor security assessment + architecture review | InfoSec + ARB | 5 business days |
| Infrastructure changes (new VPC, new region, new cloud service) | Architecture review + IAM review | InfoSec + DevOps Lead | 3 business days |
| New payment corridor or settlement channel | Full security assessment | CISO + InfoSec + relevant engineering lead | 5 business days |
| Changes to encryption, key management, or certificate handling | Cryptographic review | InfoSec + CISO | 3 business days |
| Changes to logging, audit trail, or monitoring configuration | Compliance review | InfoSec | 2 business days |
| Deployment of new container images or base OS changes | Container security scan + review | InfoSec + DevOps | 2 business days |
How to request a security review: 1. Engineering team lead creates a security review request in the ticketing system with: change description, affected services, data flows, and target deployment date. 2. InfoSec acknowledges within 1 business day. 3. Review completed within the turnaround SLA above. 4. Findings documented. Critical or high findings must be resolved before deployment. 5. InfoSec signs off. Sign-off recorded in the deployment ticket.
6. Incident Response¶
Simpaisa maintains a detailed Incident Response Playbook (separate document). This section summarises the process and links to that playbook.
Incident Response Phases¶
Detection → Triage → Containment → Eradication → Recovery → Post-Incident Review
| Phase | Owner | Key Actions | Max Duration |
|---|---|---|---|
| Detection | SOC / NOC / Any employee | Alert fires, anomaly observed, report received | — |
| Triage | SOC Lead (Rana Khubaib) | Classify severity per STD-SECURITY-041. Assign incident commander. | 30 minutes |
| Containment | Incident Commander (CISO or delegate) | Isolate affected systems. Preserve evidence. Notify stakeholders. | 2 hours (SEV-1), 4 hours (SEV-2) |
| Eradication | Engineering team + InfoSec | Remove threat. Patch vulnerability. Rotate credentials. | As required |
| Recovery | Engineering team + DevOps | Restore services. Verify integrity. Monitor for recurrence. | As required |
| Post-Incident Review | CISO | Blameless post-mortem within 5 business days. Root cause analysis. Action items. | 5 business days |
Communication During Incidents¶
| Severity | Internal Notification | External Notification | Board Notification |
|---|---|---|---|
| SEV-1 | CDO + CEO immediately. ELT within 1 hour. | Affected merchants within 4 hours. Regulators per jurisdiction requirements. | Chair notified within 24 hours. |
| SEV-2 | CDO within 1 hour. ELT at next standup. | Affected merchants if service impacted. | Included in next quarterly report. |
| SEV-3 | CDO at next security monthly. | Not required unless merchant-facing. | Aggregated in quarterly security posture report. |
| SEV-4 | Logged internally. | Not required. | Not required. |
7. Data Breach Response¶
Per STD-SECURITY-044, data breaches follow an enhanced process on top of standard incident response.
Data breach is defined as: Unauthorised access to, disclosure of, or loss of personal data (PII) or sensitive financial data (card numbers, bank account details, transaction records).
Additional steps beyond standard incident response:
- Breach assessment (within 2 hours of detection): Determine scope — what data, how many records, which markets, which data subjects.
- Legal notification (within 4 hours): Engage legal counsel. Determine regulatory notification obligations per jurisdiction:
- Pakistan (SBP): Notify SBP within 24 hours of confirmed breach.
- Bangladesh (BB): Notify Bangladesh Bank per MFS regulations.
- UAE (CBUAE): Notify CBUAE within 72 hours.
- Iraq (CBI): Notify CBI per mobile money regulations.
- Nepal (NRB): Notify NRB per payment systems directives.
- KSA (SAMA): Notify SAMA per cybersecurity framework (24 hours).
- Data subject notification: Where required by regulation or where risk to individuals is high, notify affected individuals within timeframes mandated by the relevant regulator.
- Evidence preservation: Full forensic image of affected systems. Chain of custody documented.
- Board notification: Technology & InfoSec Committee Chair notified within 24 hours of confirmed breach.
- Post-breach review: Formal review within 10 business days. Lessons learned incorporated into security controls.
8. Compliance Reporting¶
Security Posture Quarterly Report¶
The CISO produces a quarterly security posture report for the CDO and the Technology & InfoSec Board Committee.
Report contents:
| Section | Content |
|---|---|
| Executive summary | Overall security posture (Red/Amber/Green), key changes since last quarter |
| Vulnerability status | Open vulnerabilities by severity, remediation rates, SLA compliance |
| Incident summary | Incidents by severity, mean time to detect (MTTD), mean time to respond (MTTR) |
| Penetration test findings | Status of remediation for most recent pen test |
| Bug bounty summary | Submissions received, valid findings, spend |
| Compliance status | Status of regulatory obligations across all 7 markets |
| Security awareness | Training completion rates, phishing simulation results |
| Tool effectiveness | Alert volumes, false positive rates, tool coverage |
| Risk register | Top 5 security risks, mitigation status |
| Recommendations | Proposed investments, process changes, staffing needs |
Delivery schedule: - Draft to CDO: 5 business days after quarter end. - Final to Board Committee: 10 business days after quarter end (aligned with Board meeting schedule per W-01).
Monthly Security Review (CISO → CDO)¶
Per W-01, the CISO delivers a monthly security posture update to the CDO.
Format: 30-minute meeting. Written pre-read circulated 24 hours before. Content: Security score update, open findings status, active incidents, risk items requiring CDO decision.
9. Security Awareness Training¶
All Simpaisa staff (180 employees across all divisions) must complete security awareness training.
| Training | Audience | Frequency | Delivery | Pass Criteria |
|---|---|---|---|---|
| General security awareness | All staff | Annually + on hire | Online module (30 min) | Quiz score ≥ 80% |
| Phishing simulation | All staff with email | Quarterly | Simulated phishing email | Click rate < 10% (organisational target) |
| Secure coding training | All engineers (38) | Annually | Workshop (2 hours) + online module | Quiz score ≥ 80% |
| PII handling training | Staff handling personal data | Annually + on role change | Online module (45 min) | Quiz score ≥ 80% |
| Incident response tabletop | SOC + NOC + engineering leads | Bi-annually | Live tabletop exercise (2 hours) | Participation required |
| Executive security briefing | ELT | Annually | In-person briefing (1 hour) | Attendance required |
Tracking: Completion tracked in HR system. Non-completion escalated: first to line manager (2 weeks overdue), then to department head (4 weeks overdue), then to CDO (6 weeks overdue).
Phishing simulation targets: - Organisational click rate below 10%. - Any individual who clicks on 2 consecutive simulations receives mandatory 1-on-1 coaching. - Results reported in quarterly security posture report.
10. Tool Usage¶
| Tool | Purpose | Owner | Access |
|---|---|---|---|
| Snyk | SCA, container scanning, IaC scanning, licence compliance | InfoSec (integrated by DevOps) | All engineering teams via CI pipeline |
| SonarQube | SAST, code quality, security hotspot detection | InfoSec (managed by DevOps) | All engineering teams via CI pipeline |
| AWS CloudWatch | Infrastructure monitoring, alerting, log aggregation | DevOps + NOC | NOC monitors dashboards; SOC receives security-relevant alarms |
| AWS WAF | Web application firewall, rate limiting, geo-blocking | DevOps (rules managed with InfoSec input) | SOC monitors WAF logs |
| AWS GuardDuty | Threat detection, anomaly detection across AWS accounts | InfoSec | SOC receives alerts |
| AWS CloudTrail | API audit logging across all AWS accounts | InfoSec | SOC queries for investigations; logs retained per retention policy |
| Security incident tracker | Incident logging, tracking, post-mortem documentation | SOC Lead | SOC + InfoSec + CISO |
| Bug bounty platform | External researcher submissions, triage, reward management | InfoSec Manager | InfoSec + CISO |
Tool administration rules: - All security tools managed as infrastructure-as-code (Terraform) where possible. - Tool configuration changes require InfoSec review. - Alert thresholds reviewed monthly by SOC Lead and adjusted based on false positive rates. - Tool access follows least-privilege principle. Access reviews quarterly.
11. On-Call and Escalation¶
SOC On-Call Rotation¶
SOC operates with an on-call rotation to ensure 24/7 coverage for critical alerts.
| Role | Coverage | Escalation |
|---|---|---|
| SOC primary on-call | 24/7 (rotating weekly among SOC analysts) | Responds to all SEV-1 and SEV-2 alerts within 15 minutes |
| SOC Lead (Rana Khubaib) | Secondary escalation | Contacted if primary cannot resolve within 30 minutes, or for all SEV-1 |
| CISO (Danish Hamid) | Tertiary escalation | Contacted for all confirmed SEV-1 incidents, data breaches, or regulator-facing events |
| CDO | Executive escalation | Contacted for SEV-1 incidents requiring business decisions or external communication |
Escalation Matrix¶
Alert → SOC Primary On-Call
│
├── Resolved? → Log and close
│
└── Not resolved (30 min) → SOC Lead
│
├── Resolved? → Log and close
│
└── SEV-1 or not resolved (1 hour) → CISO
│
├── Containment achieved → Continue response
│
└── Business impact or data breach → CDO + CEO
Compliance with This Document¶
All security team members must follow these processes. Deviations require CISO approval and must be documented. This document is reviewed quarterly by the CISO and approved by the CDO.
Changes to this document follow the standard Architecture Practice process: propose via markdown PR, review at ARB or by CISO + CDO, merge on approval.