← Cyber Security and Resilience

Cyber security · Sub-domain two

Digital Channel and Technical Security

7 rules in this sub-domain. Each rule carries a citation, a trigger, evidence requirements and a remediation pathway.

Applicability gate

A rule's presence does not establish a direct legal duty

Confirm the entity's licensed capacity, actual services, agreement, data-processing role and Schedule 1 status. The audience-qualified publication rows below travel with this library and its public API.

Js2 2024
  • Insurance Broker: Most independent non-life Category I brokers are not directly in JS2's defined scope. A broker may be directly in scope if it separately meets a listed category, and may face contract or oversight requirements from an in-scope institution. Third-party provisions impose duties on the in-scope financial institution. They do not themselves make every supplier or intermediary directly subject to JS2.
  • Uma Binder Holder: UMA or binder-holder status is not itself listed in JS2's definition. Direct scope depends on another listed capacity; insurer contracts and oversight may create evidence requirements. JS2 paragraph 3.3 concerns juristic persons structured under an insurer or designated insurance group; it is not a blanket rule for every independent UMA or intermediary.
  • Insurer: An insurer as defined in the Insurance Act is directly in scope of JS2 from 1 June 2025. Apply proportionality and distinguish the insurer's own duty from requirements it places on third parties.
3
Critical — board exposure
2
High — significant exposure
1
Medium — material exposure
1
Low — hygiene

Rules

7 rules in Digital Channel and Technical Security

Critical

All client-facing web properties (website, quote portals, client portals) must enforce HTTPS with a valid, current TLS certificate. HTTP requests must redirect to HTTPS. HSTS (Strict-Transport-Security) header must be present. Session cookies must carry Secure and HttpOnly flags.

Trigger
HTTP not redirecting to HTTPS, HSTS header absent, TLS certificate expired or expiring within 30 days, or session cookies without Secure/HttpOnly flags
Automated
Yes — 4 machine checks

TLS configuration must achieve a minimum A rating on the SSL Labs Server Test or equivalent. This covers: TLS version (1.2 minimum, 1.3 preferred), cipher suite strength, certificate chain validity, and OCSP stapling.

Trigger
SSL certificate grades below A, or using deprecated TLS 1.0/1.1 protocols, or weak cipher suites, or certificate issued to wrong domain
Automated
Yes — 2 machine checks
Critical

Business Email Compromise (BEC) is the highest-frequency financial fraud vector against SA insurance brokers. All email-sending domains must have: SPF (hard fail -all), DKIM signing, and DMARC at minimum p=quarantine. This prevents domain spoofing and is a primary BEC defence. Missing DMARC p=none provides zero protection.

Trigger
SPF record absent or using soft-fail only (~all); DKIM not configured on primary sending domain; DMARC absent or set to p=none
Automated
Yes — 5 machine checks
Medium

HTTP security headers provide a critical layer of browser-side protection against XSS, clickjacking, MIME sniffing, and data leakage. These headers are visible in any HTTP response and their absence signals a basic security gap to both regulators and attackers.

Trigger
Content-Security-Policy header absent; X-Frame-Options header absent; X-Content-Type-Options: nosniff absent; Referrer-Policy absent
Automated
Yes — 4 machine checks

Public exposure of administrative interfaces (/admin, /wp-admin, /cpanel, /phpmyadmin, etc.) without strong authentication is one of the most exploited weaknesses in SA SME environments. Admin portals must not be publicly reachable or must require MFA before any content is served.

Trigger
Admin portal accessible from public internet without MFA, or returns a login page without any additional authentication layer, or server/CMS version information exposed in HTTP headers
Automated
Yes — 2 machine checks

CYB-11 · RFC 9116 / NCSC guidance / Joint Standard 2 best practice

Vulnerability disclosure — security.txt file present for responsible disclosure

Low

The security.txt standard (RFC 9116) defines how organisations can communicate their vulnerability disclosure policy and security contact. Its presence signals security maturity and enables ethical hackers to report issues before they are exploited. Required at /.well-known/security.txt.

Trigger
No security.txt file at /.well-known/security.txt; or security.txt present but expired (Expires field in the past)
Automated
Yes — 1 machine check
High

Domain hijacking and typosquatting are primary vectors for broker impersonation in SA. Attackers register domains like 'apexinsurancecoza.com' or 'apex-insurance.co.za' to intercept clients, divert payments, or conduct phishing campaigns. Registry Lock prevents unauthorised domain transfers.

Trigger
Domain registrar lock not enabled; no lookalike domain monitoring in place; known typosquatting domains identified against the organisation's primary domain
Automated
Yes — 2 machine checks