For ECC 2:2024 practice 2-5-3, network security management SIEM log requirements should show that network controls are operating: segmentation and firewall enforcement, production separation, secure browsing, wireless access, port and protocol restrictions, IPS/IDS coverage, protected DNS, APT protection, and DDoS defenses. The control does not expressly mandate a SIEM, but SIEM records are strong supporting evidence when they identify the affected system, source and destination, time, action taken, rule or policy involved, and the outcome of the security event. Compliance also requires approved policies, current diagrams, configuration evidence, and documented reviews—not logs alone.
What does ECC 2:2024 practice 2-5-3 officially require?
The official requirement for practice 2-5-3 states: “The cybersecurity requirements for network security management must include at least the following.”
This wording matters during an NCA review. It means the organization must first define these requirements in its network security management policy or standard, obtain approval from the organization head or authorized representative, and then demonstrate that the stated requirements are implemented. A SIEM can help demonstrate operation and monitoring, but it cannot replace the approved requirement, the technical configuration, or the evidence that a control was reviewed.
In plain English, the required areas are as follows:
| ECC requirement | What it means in practice | Useful SIEM evidence |
|---|---|---|
| 2-5-3-1: Segmentation and defense in depth | Define trust zones and isolate them through firewalls, DMZs, VLANs, and layered technical and administrative controls. | Firewall allow/deny events between zones, DMZ connection logs, VLAN-related alerts, and policy-change audit records. |
| 2-5-3-2: Production, test, and development separation | Keep production networks distinct from development and test networks, with documented addresses and diagrams. | Alerts for prohibited traffic from development or test subnets to production servers, plus firewall rule hits that enforce separation. |
| 2-5-3-3: Secure browsing and internet connectivity | Restrict suspicious websites, file-sharing and storage services, and remote-access websites; use proxy-based inspection and filtering where applicable. | Proxy URL category, user, action, destination domain, malware verdict, and blocked upload or download events. |
| 2-5-3-4: Wireless security | Use strong authentication and encryption, isolate corporate and guest wireless networks, and assess risk before connecting wireless to the internal network. | Wireless authentication successes and failures, device identity, SSID, assigned VLAN, encryption status, and rogue access-point alerts. |
| 2-5-3-5: Ports, protocols, and services | Allow only required services, disable unused ports and protocols, and formally approve firewall-rule changes and periodic reviews. | Denied-port scans, newly permitted services, firewall configuration changes, administrator identity, approval reference, and review alerts. |
| 2-5-3-6: IPS/IDS | Deploy and maintain intrusion detection and prevention coverage across internal, DMZ, and wireless environments. | IPS signatures, severity, source and destination, prevention action, affected zone, and sensor-health status. |
| 2-5-3-7: DNS security through Haseen platform | Use documented, protected DNS services and avoid public DNS services such as Google DNS or provider DNS where prohibited by the requirement. | DNS security blocks, suspicious domains, resolver configuration changes, DNS poisoning indicators, and queries to unapproved resolvers. |
| 2-5-3-8: APT protection for browsing channels | Use advanced protection capable of detecting zero-day malware and other advanced threats introduced through web browsing. | Sandbox verdicts, file hashes, malware family, web gateway action, detonation results, and endpoint follow-up events. |
| 2-5-3-9: DDoS protection | Protect internet-facing services against distributed denial-of-service attacks and reduce related business risk. | Traffic-volume anomalies, mitigation activation, attacked IP or URL, upstream-provider events, and service-availability alerts. |
Which network security management SIEM log requirements apply to my organization?
Practice 2-5-3 applies to organizations within the scope of the Essential Cybersecurity Controls and to the network services, infrastructure, and connected environments they operate or manage. For an IT manager, this includes on-premises networks, cloud-connected networks, branch connectivity, internet gateways, wireless networks, DMZ services, and third-party-managed devices where the organization remains accountable for security.
The requirement is triggered whenever a network capability exists or is introduced. If there is wireless access, wireless security and the pre-connection risk assessment apply. If an organization provides internet browsing, secure web access controls and supporting monitoring apply. If it maintains a production application and separate development environment, segregation must be documented and technically enforced. If a service is internet-facing, DDoS protection should be considered and evidenced.
For SIEM purposes, collect logs from the controls that implement the requirement, rather than assuming that endpoint logs alone are enough. Typical sources include Palo Alto Networks or Fortinet firewalls, Cisco ISE or Aruba ClearPass, Cisco Secure Firewall or Check Point IPS, Zscaler or Netskope secure web gateways, DNS security platforms, wireless controllers, cloud load balancers, and DDoS providers.
A practical event schema for SIEM logging requirements for network security management should preserve the following fields:
timestamp=2026-07-16T09:42:18+03:00 device=PA-VM-EDGE-01 event_type=threat source_ip=10.40.18.27 source_zone=DEV destination_ip=10.20.5.14 destination_zone=PROD destination_port=1433 protocol=tcp policy_name=deny-dev-to-prod action=deny user=ahmed.alharbi severity=high rule_change_ticket=CHG-2026-1847
Not every log source will populate every field, but the SIEM should preserve enough context for the security team and an assessor to understand what happened, what control acted, and whether the action was allowed, blocked, detected, or escalated.
What does compliant practice look like during an NCA review?
Compliant practice is a coherent evidence set: an approved policy, implementation records, current network documentation, management-approved changes, and samples showing the controls in operation. The following examples illustrate what an assessor could reasonably accept as evidence.
- Segmentation evidence with operational confirmation. A network security management policy, approved by the authorized representative, defines Internet, DMZ, corporate user, server, production, development, wireless corporate, and guest zones. A current network diagram shows the boundaries. Firewall configuration exports show explicit rules between zones, while SIEM searches demonstrate that the
deny-dev-to-prodrule is actively blocking unauthorized access attempts. - Production and development isolation. A 650-person organization operating a digital banking platform maintains production workloads in
10.20.0.0/16, development in10.40.0.0/16, and testing in10.50.0.0/16. Its assessor evidence includes the server address inventory, a diagram showing separate VLANs, firewall rules preventing direct development-to-production access, and a monthly SIEM report of attempted cross-environment connections. Approved, time-limited jump-host access is logged separately and linked to change tickets. - Secure browsing and APT protection. A secure web gateway such as Zscaler Internet Access sends URL filtering, SSL inspection, file-sandboxing, and user-attribution events to Microsoft Sentinel. The organization can show a blocked attempt to upload files to an unapproved storage site, a policy restricting remote-access websites, and a sandbox verdict that prevented a suspicious zero-day-like download from reaching an employee device.
- Wireless controls backed by risk evidence. A fintech company with 180 employees uses WPA3-Enterprise with Cisco ISE authentication, assigns employees to a corporate wireless VLAN, and places visitors on an internet-only guest VLAN. The evidence package includes the approved Wireless Security Standard, controller screenshots showing encryption and identity-based access, a risk assessment for the wireless-to-internal-network connection, remediation actions, and SIEM alerts for repeated authentication failures or rogue access points.
- Controlled firewall, IPS, DNS, and DDoS management. The security team produces an annual firewall and IPS configuration review, the representative’s approval for changes, and a record of the rules updated. SIEM dashboards show IPS prevention events in internal, DMZ, and wireless zones; DNS security events through the required protected DNS service; and DDoS provider mitigation events for public services. A screenshot alone is weaker than a screenshot paired with dated review records, ownership, and approval.
What should an assessor be able to trace from a SIEM event?
An assessor should be able to trace a meaningful event from detection to governance. For example, an IPS alert should identify the sensor and network zone, the source and destination, the signature or detection reason, whether traffic was prevented, who investigated it, and whether a firewall or IPS rule change followed. If a configuration change was made, the organization should be able to provide the approved change request and demonstrate that the change was reviewed.
This is the practical distinction between retaining logs and operating a governed monitoring capability. Network security SIEM logging should support evidence, investigation, and verification that the documented controls work as intended.
Frequently asked questions about ECC 2-5-3 SIEM logs
Does ECC 2-5-3 require a SIEM?
No. Practice 2-5-3 requires network security management controls and evidence of their implementation; it does not specifically name a SIEM. A SIEM is valuable because it centralizes and correlates evidence from firewalls, IPS/IDS, DNS, web gateways, wireless controllers, and DDoS services.
What firewall logs should be sent to the SIEM for ECC compliance?
At minimum, send allowed and denied traffic events for relevant boundaries, threat-prevention events, administrative logins, configuration changes, rule changes, VPN events, and system-health alerts. Include timestamp, source and destination, protocol, port, zone, rule name, action, device, and administrator or user identity where available.
Are screenshots enough for an NCA assessment?
No. Screenshots can support evidence, particularly for configuration and technology deployment, but they should be accompanied by approved policies, network diagrams, inventories, risk assessments where required, review records, and change approvals. Screenshots should be dated and clearly identify the relevant device, setting, or service.
How often should firewall and IPS configurations be reviewed under ECC 2-5-3?
The requirement calls for periodic review, at least annually, of protection-system configurations. Reviews and updates should be documented, tracked in an automation tool or controlled register, and approved by the authorized representative before necessary changes are applied.
Next step: Map each ECC 2-5-3 requirement to its policy statement, technical owner, evidence artifact, and SIEM data source before scheduling your internal NCA readiness review.
