Technology & Operational Resilience — NFSA Guidance (NLA)
NFSA & NGA Rules & Guidance/Technology & Operational Resilience

Technology & Operational Resilience

Guidance on systems integrity, cybersecurity, incident management, and business continuity. These expectations support reliable service delivery and evidence-based oversight.

Applies to
NFSA Licensees
Focus
Technology • Security • Continuity
Evidence
Logs • Policies • Test results
Status
Active guidance

1. Objective

baseline expectations

NFSA licensees should maintain technology and operational resilience that prevents avoidable outages, protects client data, and ensures control evidence is retrievable without delay. The intent is not “perfect security” — it is consistent, repeatable controls with documented accountability.

Core principle:If a control is important, it must be measurable, logged, and testable.

2. Systems integrity & access control

identity • change • auditability
Control outcome Minimum standard Typical failure
Controlled admin access Role-based access, least privilege, named accounts, MFA, and periodic access reviews. Shared logins, no MFA, no review trail.
Controlled change Material changes approved and recorded before deployment; rollback documented. Unlogged production edits; emergency changes become permanent.
Auditability System logs are retained, time-synchronised, and tamper-resistant where feasible. Logs overwritten quickly; no time sync; gaps during incidents.
Configuration integrity Key configuration baselines documented; drift monitored for critical assets. No baseline; “we just know how it is set.”
Evidence examples (what “good” looks like)

Access review exports, MFA enforcement settings, change tickets with approvals, deployment logs, code repo history, and immutable log storage summaries (or equivalent evidence of retention & integrity).

3. Cybersecurity hygiene (minimums)

prevent • detect • respond
  • Vulnerability management:routine scanning and prioritised remediation for critical findings.
  • Endpoint and server hardening:baseline configurations, patch cadence, and malware controls.
  • Credential protection:MFA, password hygiene, secret storage, and rotation for privileged credentials.
  • Network segmentation:production/admin separation where practical, and restricted inbound access.
  • Security monitoring:alerting for suspicious logins, privilege escalation, and anomalous activity.
Minimum evidence:scan summaries, patch records, access logs, incident register, and security policy pack.

4. Incident management

severity • escalation • lessons learned

Licensees should maintain a documented incident process that covers detection, triage, escalation, containment, recovery, and post-incident review. Incidents should be categorised by severity and time-to-restore targets should be recorded.

  • Severity model:clear definitions (e.g., Sev-1 to Sev-4) linked to response urgency.
  • Escalation:on-call or escalation contacts for technology, security, operations, and leadership.
  • Recordkeeping:incident timeline, decisions, communications, and remediation actions.
  • Post-incident review:root cause, contributing factors, corrective actions, and owners.
Suggested incident record fields

Date/time, detection source, severity, impacted systems, customer impact, containment actions, recovery steps, evidence links (logs/screenshots), root cause, corrective actions, and completion dates.

5. Business continuity & disaster recovery

BCP • DR • testing
  • Backups:defined frequency, encrypted storage, and tested restoration procedures.
  • Recovery objectives:practical RTO/RPO targets for critical services.
  • Redundancy:avoid single points of failure for core systems where feasible.
  • Testing:periodic exercises (tabletop + technical restoration tests) with documented outcomes.
Simple reality check:If you’ve never restored from backup under pressure, you don’t have backups — you have hopes.

6. Third-party technology dependencies

outsourcing • concentration risk

Where licensees depend on vendors (hosting, KYC, payments, trading platforms, game providers, analytics), they should maintain visibility over service performance, security posture, and exit readiness.

  • Maintain a vendor register with service criticality and data access classification.
  • Document SLAs, incident responsibilities, and escalation paths.
  • Evidence periodic reviews (performance and security) for critical vendors.
  • Maintain an exit/transition plan for high-impact dependencies.

7. Oversight-ready evidence pack

what to keep ready

Licensees should be able to provide an evidence pack promptly when requested. At minimum, it should include:

  • Access controls: roles, MFA enforcement, access reviews, privileged account list.
  • Change management: deployment log, approvals, and change history for material releases.
  • Security: vulnerability scan summaries, patch cadence evidence, incident register.
  • Continuity: backup policy, restoration test outcomes, DR/BCP testing records.
  • Logging: retention settings, audit log extracts, time-sync evidence.
Note:Missing logs, shared admin access, and undocumented production changes are common reasons evidence is considered incomplete.

8. Cross-links

related guidance