The Saudi Communications, Space and Technology Commission (CST, formerly CITC) set this framework as the minimum cybersecurity baseline for ICT sector service providers. Providers classified as critical national infrastructure follow the NCA's Essential Cybersecurity Controls; all others follow numbered controls in six domains: governance, asset management, risk management, logical security, physical security and third party security.
Free account needed to download. You come straight back to the file.
Who it is for. Service providers in the Saudi ICT sector that CST licenses or registers. CST decides how far the framework applies to each provider, and which of its three compliance levels and what dates a provider has to meet.
What this list covers. Second Version, October 2023, the English text on CST's regulations page for Decision 424/1442 (dated 15/09/2020, which issued the first version). CST says the English is not an official translation and the Arabic original prevails. Check CST's site for later versions: 228 controls. Each has a reference, a heading and a sentence in plain English.
| Ref | Control | What it requires |
|---|---|---|
| Sec. 5 (ECC) | Follow the NCA Essential Cybersecurity Controls | A provider that CST and the NCA classify as critical national infrastructure complies with the NCA's Essential Cybersecurity Controls instead of the control list in section 6. |
| Sec. 5, item 1 | Own your cybersecurity | Take full responsibility for your own cybersecurity. |
| Sec. 5, item 3 | Apply the controls to the compliance targets | Apply and implement the controls in this section in line with the compliance requirements CST specifies. |
| Sec. 5, item 4 | Copy CST on NCA reports | Give CST a copy of the compliance reports you submit to the NCA. |
| Sec. 5, item 5 | Share critical risks with CST | Share your critical cybersecurity risks with CST. |
| Sec. 5, item 6 | Report incidents to the NCA and CST | When a cybersecurity incident occurs, report it to the NCA straight away and notify CST. |
| Sec. 5, item 7 | Share alerts and indicators with CST | Share security alerts, threat intelligence, indicators of compromise and incident reports with CST. |
| Sec. 5, item 8 | Accept extra controls and checks | Expect CST to add controls when needed and to set targets and check compliance through self-assessment, inspections, workshops and audits. |
| Ref | Control | What it requires |
|---|---|---|
| 1.1.1 | Set strategy requirements | Document what the cybersecurity strategy must cover: your mission and activities, the laws that apply, the security programme and the commitment of top management. |
| 1.1.2 | Top management approves the strategy | Get the cybersecurity strategy approved by top management. |
| 1.1.3 | Plan the strategy's delivery | Make sure the action plan that delivers the strategy covers its activities, budget, timeline and resources. |
| 1.1.4 | Keep strategy and plan current | Measure and review the strategy and its action plan, and update both when laws change, the organisation changes or earlier plans teach lessons. |
| Ref | Control | What it requires |
|---|---|---|
| 1.2.1 | Define the security organisation | Document what the security organisation needs: a committee with members from across the business, the functions to deliver the plan, a direct line to top management and clearly separated duties. |
| 1.2.2 | Stand up the security organisation | Put the cybersecurity organisation you defined into place. |
| 1.2.3 | Deliver the plan through it | Carry out the action plan through the cybersecurity organisation. |
| 1.2.4 | Committee oversees delivery | Have the cybersecurity committee oversee the action plan: monitor progress, resolve conflicts and enforce the improvements that are needed. |
| 1.2.5 | Improve the organisation | Keep measuring, reviewing and improving the requirements for the cybersecurity organisation, so that it stays efficient, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.3.1 | Set compliance requirements | Document the compliance requirements: national cybersecurity laws and rules, recognised international or cross-border commitments, and your own internal requirements. |
| 1.3.2 | Run a compliance process | Run a process that finds, records and communicates compliance requirements on a regular basis, for example when a new regulatory requirement takes effect. |
| 1.3.3 | Build compliance into the organisation | Make sure the compliance requirements are built into how the organisation works. |
| 1.3.4 | Improve compliance | Keep measuring, reviewing and improving the compliance requirements and how well the compliance process works, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.4.1 | Set audit requirements | Document the audit requirements: independent audits at regular intervals, protection and retention of audit records, and reporting to top management. |
| 1.4.2 | Run internal audit | Run an internal audit process that checks you meet the compliance requirements you identified. |
| 1.4.3 | Commission independent audits | Have independent auditors review how you meet the compliance requirements, at planned intervals and when significant changes occur. |
| 1.4.4 | Take findings to top management | Record audit findings and recommendations and present them to top management. |
| 1.4.5 | Protect audit records | Protect audit records from unauthorised access, change and destruction. |
| 1.4.6 | Keep audit records as proof | Retain audit records as proof that you comply with laws and regulations. |
| 1.4.7 | Improve the audit programme | Keep measuring, reviewing and improving the audit requirements, and the effectiveness of the audit process and its reviews, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.5.1 | Set training requirements | Document the training requirements: goals and scope, how many sessions a year and how often, and the resources set aside. |
| 1.5.2 | Run a training programme | Run an awareness and training programme with goals, audience and ways to check learning, covering roles, current threats, unauthorised kit and software, device and email handling, and clear desk and screen. |
| 1.5.3 | Test what people learned | Add regular tests of how well the training works, such as checking whether staff click a suspicious email link, and record the results. |
| 1.5.4 | Say when training is due | Define when training must be given, such as for new users and when systems or job roles change. |
| 1.5.5 | Train specialist groups | Give specialised security training to groups such as the security team, IT staff, developers, risk staff, privileged users and executives. |
| 1.5.6 | Improve training | Keep measuring, reviewing and improving the training requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.6.1 | Set customer awareness requirements | Document the customer awareness requirements: goals and scope, how many sessions a year and how often, and the resources set aside. |
| 1.6.2 | Run a customer awareness programme | Run a programme that tells customers about emerging threats such as phone scams and impersonation calls, and gives advice that fits the service they use. |
| 1.6.3 | Deliver it regularly | Run the customer awareness programme for your customers on a regular basis. |
| 1.6.4 | Improve customer awareness | Keep measuring, reviewing and improving the customer awareness requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.7.1 | Set project security requirements | Document how security is built into project management, such as security staff on project teams and security objectives that run through every project phase. |
| 1.7.2 | Assess risk on every project | Assess cybersecurity risk when each project starts and during it, using your risk assessment approach, and define mitigation plans. |
| 1.7.3 | Track project risks | Track the cybersecurity risks you identify and check that the mitigation plans are carried out as the project runs. |
| 1.7.4 | Improve project security | Keep measuring, reviewing and improving the requirements for cybersecurity in project management, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 1.8.1 | Set people security requirements | Document security rules for staff and contractors before, during and after employment: background checks, skilled people on critical systems, signed conduct terms and acceptable use. |
| 1.8.2 | Adjust access on role change | When someone is reassigned or transferred, take the needed steps, such as changing their access to fit the new role. |
| 1.8.3 | Investigate staff breaches | Investigate suspected breaches of security requirements by staff, and take fitting disciplinary action. |
| 1.8.4 | Close out leavers | When work ends or someone leaves, revoke their access, recover assigned assets and keep access to information they controlled. |
| 1.8.5 | Improve HR security | Keep measuring, reviewing and improving the requirements for cybersecurity in human resources, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.1.1 | Set discovery requirements | Document how assets are discovered: an inventory of software, hardware, data and critical assets, how often the inventory is updated, and who owns each asset. |
| 2.1.2 | Discover and record assets | Run a discovery process, using a tool where it helps, to find all your information assets and update the inventory. Give every asset an owner. |
| 2.1.3 | Keep the inventory current | Review and update the inventory at the set frequency and whenever assets are added or removed. |
| 2.1.4 | Automate discovery | Use dedicated, automated tools to discover assets, and track them all from one central system. |
| 2.1.5 | Improve discovery | Keep measuring, reviewing and improving the asset discovery requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.2.1 | Set classification requirements | Document how assets are classified and labelled, and the protection for each level when identifying, handling, transferring, storing, returning, deleting and disposing of them. |
| 2.2.2 | Classify and label assets | Classify and label the assets in your inventory against set criteria, such as criticality, business value, legal needs, confidentiality, integrity and availability. |
| 2.2.3 | Improve classification | Keep measuring, reviewing and improving the asset classification requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.3.1 | Set BYOD requirements | Document security rules for personal devices: keep personal and business data apart, limit device use as the business sees fit, restrict access to critical systems and delete business data securely. |
| 2.3.2 | Enforce the BYOD rules | Enforce the personal-device rules across the organisation. |
| 2.3.3 | Delete business data after use | Securely delete the organisation's information from personal devices once the job is done and the information is no longer needed. |
| 2.3.4 | Encrypt business data on devices | Make sure the organisation's information held on personal devices is encrypted. |
| 2.3.5 | Improve BYOD security | Keep measuring, reviewing and improving the personal-device security requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.4.1 | Set acceptable use rules | Document what counts as acceptable use of information assets. |
| 2.4.2 | Put the rules into practice | Put the acceptable use rules into effect, for example barring unwanted software, controlling access to web pages and allowing removable media only where the business needs it. |
| 2.4.3 | Improve acceptable use | Keep measuring, reviewing and improving the acceptable use requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.5.1 | Set maintenance requirements | Document requirements for maintaining assets: the maintenance itself, tracking and monitoring, and a recovery plan. |
| 2.5.2 | Maintain and repair assets | Maintain and repair your information assets, including those off site, and keep a log of the work. |
| 2.5.3 | Recover assets | Follow your recovery plan to restore assets during or after a security incident. |
| 2.5.4 | Monitor assets by class | Monitor information assets in a way that fits their classification. |
| 2.5.5 | Improve maintenance | Keep measuring, reviewing and improving the asset maintenance requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 2.6.1 | Set disposal requirements | Document rules for disposing of assets that follow each asset's classification and label in your inventory. |
| 2.6.2 | Dispose of assets securely | Run a disposal process using suitable methods, such as secure erase, drilling or shredding, so nothing is disclosed or altered from information on disposed assets. |
| 2.6.3 | Improve disposal | Keep measuring, reviewing and improving the secure disposal requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 3.1.1 | Set risk assessment requirements | Document the purpose and scope of risk assessment, how often and when to do it, and that it covers risks to your assets, to individuals and to other organisations. |
| 3.1.2 | Assess risk | Identify risks into a register, analyse likelihood and impact, decide what to treat or accept against your risk appetite with top management sign-off, and report top risks and remediation plans to CST. |
| 3.1.3 | Build into risk management | Fit risk assessment into your risk management framework, and run it at least early in major technical projects or changes and before launching new products and services. |
| 3.1.4 | Improve risk assessment | Keep measuring, reviewing and improving the risk assessment requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 3.2.1 | Set treatment requirements | Document requirements for risk treatment and monitoring, including the treatment plan and the monitoring plan. |
| 3.2.2 | Treat risks | Run a process that describes how assessed risks are treated and produces a risk treatment plan. |
| 3.2.3 | Monitor risks | Run a process that reviews identified risks, progress on the treatment plan, residual risk and the status of accepted risks. |
| 3.2.4 | Improve treatment and monitoring | Keep measuring, reviewing and improving the risk treatment and monitoring requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.1.1 | Set cryptography requirements | Document cryptography requirements: the approved protocols and techniques with their limits (for example no self-signed certificates), and when to apply them to data in transit, at rest and in use. |
| 4.1.2 | Keep an approved crypto list | Keep a list of cryptographic products, algorithms and protocols that respects legal, technical and national limits, approved by the responsible roles. |
| 4.1.3 | Use cryptography through the data life cycle | Use the approved cryptography to protect information in transit, at rest and in use, according to its classification. |
| 4.1.4 | Manage key life cycles | Run a process that covers generating, protecting, archiving, recovering and destroying cryptographic keys. |
| 4.1.5 | Improve cryptography | Keep measuring, reviewing and improving the cryptography requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.2.1 | Set change requirements | Document how changes to information assets that affect security are identified, classified and prioritised. |
| 4.2.2 | Run change management | Run a change process that authorises security-relevant changes such as patches, configuration fixes and new or upgraded equipment. |
| 4.2.3 | Plan, test and approve changes | Plan and test changes, assess their security impact, tell the people affected and get approval from the authorised people or committee. |
| 4.2.4 | Handle emergency changes | Extend the change requirements to include a procedure for emergency changes. |
| 4.2.5 | Improve change management | Keep measuring, reviewing and improving the change management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.3.1 | Set vulnerability requirements | Document vulnerability management: scope, tools and reporting, how often to scan, and fix timeframes based on criticality. |
| 4.3.2 | Scan, analyse and report | Scan inventoried assets at the set frequency, rate each finding and set its fix deadline, then report findings and the asset's criticality to the right teams with the recommended action. |
| 4.3.3 | Scan on triggering events | Also scan after events such as a product release, a major technical change or new equipment joining the network. |
| 4.3.4 | Use specialised scanners | Use specialised, automated vulnerability scanners, for example dedicated tools for web servers and mobile apps. |
| 4.3.5 | Enrich vulnerability ratings | Improve how findings are classified and reported by using other inputs such as penetration testing and threat intelligence. |
| 4.3.6 | Improve vulnerability management | Keep measuring, reviewing and improving the vulnerability management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.4.1 | Set patch requirements | Document patch management: its scope, tools and triggers, a patch testing environment, and how often to patch, including regular patching. |
| 4.4.2 | Plan and run patching | Run a process that produces a remediation plan from the vulnerability report and risk assessment, tests patches and takes backups before production, follows change management and keeps to regular patch releases. |
| 4.4.3 | Confirm patches worked | Check that installed patches succeeded and that the vulnerabilities they target are fixed. |
| 4.4.4 | Handle emergency patches | Extend the patch requirements to cover emergency patching for highly critical vulnerabilities. |
| 4.4.5 | Patch all assets regularly | Apply patch packages or software updates regularly on all information assets. |
| 4.4.6 | Automate patching | Automate and enforce patching wherever possible, for example on end-user devices. |
| 4.4.7 | Drive remediation with intelligence | Strengthen the remediation plan using threat intelligence, penetration testing and other sources, then carry it out. |
| 4.4.8 | Improve patch management | Keep measuring, reviewing and improving the patch management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.5.1 | Set network requirements | Document network security: managing and controlling your networks and the assets connected to them, segregating networks, and protecting network services and the information that crosses them. |
| 4.5.2 | Keep a network plan | Keep a network plan that shows the real state of the network, including all connections in, network devices and critical servers. |
| 4.5.3 | Control traffic in and out | Control incoming and outgoing traffic against your network requirements, for example blocking malicious traffic, watching switching load and curbing unwanted email and SMS. |
| 4.5.4 | Guard the network boundary | Let only trusted, authorised protocols and IP ranges cross the boundary, for example through firewalls, and switch off unused protocols to shrink the attack surface. |
| 4.5.5 | Protect data crossing the network | Protect information carried over your network from interception, copying and change, and keep it confidential and intact, for example by encrypting it. |
| 4.5.6 | Divide the network into zones | Split the network into zones by criticality, for example separating production from development and test, and user workstations from authentication servers. |
| 4.5.7 | Restrict network access | Limit access to wired and wireless networks using the access control list from identity and access management. |
| 4.5.8 | Secure telecom traffic | Protect end-user data, voice and signalling carried over your telecommunications network, for example VoIP and SIP traffic and SS7. |
| 4.5.9 | Keep customer networks apart | Keep hosted customer networks separate from your telecommunications operational network. |
| 4.5.10 | Work with interconnected operators | Cooperate with organisations whose networks connect to yours to spot and stop malicious activity such as spam, DDoS, odd traffic patterns and caller ID spoofing. |
| 4.5.11 | Secure interconnection points | Secure your interfaces to other networks, such as Internet Exchange Points, for example by protecting BGP, building in redundancy and using strong cryptography. |
| 4.5.12 | Defend against network attacks | Extend the network requirements to handle internal and external attacks on your network, such as DoS and DDoS. |
| 4.5.13 | Avoid congestion | Put mechanisms in ICT facilities to detect and avoid congestion that disrupts service, for example extra capacity to balance the load. |
| 4.5.14 | Analyse and filter all traffic | Use specific tools to analyse and filter all traffic, for example port or host filtering, to detect unauthorised traffic on the network. |
| 4.5.15 | Improve network security | Keep measuring, reviewing and improving the network security requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.6.1 | Set logging requirements | Document logging and monitoring: which events to log, such as login attempts, configuration changes and firewall logs, how logs are monitored and analysed, and how long they are kept and protected. |
| 4.6.2 | Switch on logging | Turn on event logging for your information assets and record events such as user activity, exceptions, security events and privileged operations. |
| 4.6.3 | Protect the logs | Protect log information and logging facilities from unauthorised access and tampering. |
| 4.6.4 | Review logs and escalate | Review event logs regularly and report suspicious events and anomalies to the responsible people through incident management. |
| 4.6.5 | Retain logs | Keep logs for the period your requirements set. |
| 4.6.6 | Centralise log analysis | Collect, monitor and analyse events in a log management tool, such as a SIEM, with advanced detection and integration. |
| 4.6.7 | Watch critical assets live | Monitor and review the event logs of critical information assets in real time. |
| 4.6.8 | Sharpen detection | Improve how events are detected by using dedicated tools, such as threat intelligence platforms, to update the rules in your log tools. |
| 4.6.9 | Improve logging and monitoring | Keep measuring, reviewing and improving the logging and monitoring requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.7.1 | Set access requirements | Document identity and access management: user and privileged accounts, granting and revoking access, authentication and authorisation (for example two-factor for remote access) and password management. |
| 4.7.2 | Allocate and revoke access rights | Run a process that gives users access by role, changes it when jobs change, follows need-to-know and least privilege with separation of duties, keeps an access control list current and removes access when contracts end. |
| 4.7.3 | Control privileged access | Control and restrict who gets privileged access rights and how they use them. |
| 4.7.4 | Require multi-factor authentication | Require multi-factor authentication for sensitive and critical systems and for remote access. |
| 4.7.5 | Enforce password rules | Enforce your password rules, such as strong passwords, regular changes and lockouts after repeated failures, and protect authentication data from exposure, for example by encrypting it in transit. |
| 4.7.6 | Review access rights | Review user identities and access rights regularly, at a frequency that reflects account types and asset criticality, so access still follows the access control principles. |
| 4.7.7 | Automate access management | Extend the access requirements to use tools that automate and centralise identity and access management. |
| 4.7.8 | Use dedicated admin systems | Use dedicated systems for tasks that need administrative access, such as configuring critical systems. |
| 4.7.9 | Improve access management | Keep measuring, reviewing and improving the identity and access management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.8.1 | Set whitelisting requirements | Document application whitelisting: a list of authorised software and the approved whitelisting tools. |
| 4.8.2 | Publish an index of authorised software | Create and share an index of authorised software, covering applications, software libraries and digitally signed scripts. |
| 4.8.3 | Review the index | Review and update the index of authorised software on a regular basis. |
| 4.8.4 | Enforce whitelisting | Use whitelisting tools so that only authorised software runs on any information asset, and make sure the tool cannot be disabled or bypassed. |
| 4.8.5 | Improve whitelisting | Keep measuring, reviewing and improving the application whitelisting requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.9.1 | Set incident requirements | Document incident management: definition, identification, classification, prioritisation and response, the reporting structure, testing the response, evidence collection and learning from incidents. |
| 4.9.2 | Run incident response | Run a response process: detect incidents from logged events, classify them by set criteria, contain, eradicate and recover within your timeframes, write a report with lessons learned, and report incidents to CST. |
| 4.9.3 | Exercise the response | Run regular exercises to test how well incident response works, for example communication channels and response times. |
| 4.9.4 | Automate incident handling | Extend the incident requirements to use tools that automate the process and connect to other systems. |
| 4.9.5 | Use threat intelligence | Gather threat intelligence and use it when analysing security events. |
| 4.9.6 | Form a forensic team | Set up a forensic team to investigate security incidents. |
| 4.9.7 | Preserve evidence and learn | Identify, collect and preserve evidence from incidents, and use what you learn to reduce the likelihood and impact of future incidents. |
| 4.9.8 | Improve incident management | Keep measuring, reviewing and improving the incident management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.10.1 | Set malware requirements | Document malware handling: detection and prevention controls, and the technical controls that protect your assets. |
| 4.10.2 | Run endpoint protection | Use endpoint protection software, keep its signatures updated and stop users from deactivating or altering it. |
| 4.10.3 | Block malicious sources | Block sources of malicious traffic, for example with internet filters, email filters against phishing and limits on downloading dangerous content. |
| 4.10.4 | Scan removable media | Protect removable media against malware, for example by scanning it when it is inserted or connected. |
| 4.10.5 | Use advanced detection | Use advanced malware detection, for example DNS query logging to spot lookups of known malicious domains. |
| 4.10.6 | Alert on malware events | Use advanced logging and monitoring tools to analyse and alert on detected malware events. |
| 4.10.7 | Improve malware handling | Keep measuring, reviewing and improving the malware handling requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.11.1 | Set information protection requirements | Document information protection: classification levels and criteria, privacy, ownership, protection, transmission and retention of information, and privacy of personal and other sensitive data under your compliance requirements. |
| 4.11.2 | Classify information | Run a process that sorts information by your classification criteria and handles critical information by business value and legal, technical, national and cross-border needs. |
| 4.11.3 | Protect information with controls | Protect information in transit, at rest and in use with security mechanisms, taking account of your cryptography requirements and data loss prevention techniques. |
| 4.11.4 | Keep production data out of test | Stop information moving from the production environment to other environments, and keep critical-system data out of test and development environments. |
| 4.11.5 | Set retention periods | Set retention periods that match organisational needs and the law, and keep critical information no longer than necessary. |
| 4.11.6 | Improve information protection | Keep measuring, reviewing and improving the information protection requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.12.1 | Set backup requirements | Document backup and recovery: the scope of online and offline backups and their retention, fast recovery after incidents, regular backups, and protection and availability of backups. |
| 4.12.2 | Run a backup process | Run a backup process driven by business needs such as recovery point objectives, covering online and offline backups and how well they cover your assets, for example full-system images. |
| 4.12.3 | Run a recovery process | Run a recovery process that restores assets within an acceptable time, based on their classification. |
| 4.12.4 | Protect the backups | Keep backups confidential, intact and available in adverse situations, for example through encryption and physical protection. |
| 4.12.5 | Use an alternate site | Set up an alternate storage or backup site with security measures equal to the primary site. |
| 4.12.6 | Test backup and recovery | Keep testing and reviewing the backup and recovery processes to check they work. |
| 4.12.7 | Automate backup and recovery | Extend the backup requirements to use tools that automate the backup and recovery processes. |
| 4.12.8 | Improve backup and recovery | Keep measuring, reviewing and improving the backup and recovery requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.13.1 | Set hardening requirements | Document configuration management and hardening: secure images and baseline configurations for assets and for the software and hardware you use. |
| 4.13.2 | Apply baseline settings | Put the defined baseline configuration settings in place on your information assets. |
| 4.13.3 | Harden systems and devices | Harden systems and devices to recognised industry practice, for example by disabling default configurations installed on network devices. |
| 4.13.4 | Keep functions to a minimum | Restrict unnecessary functions, such as unauthorised ports and services, so assets provide only essential capabilities. |
| 4.13.5 | Check settings against the baseline | Monitor configuration settings and verify them against the baseline. |
| 4.13.6 | Alert on configuration drift | Use a dedicated tool to check configuration settings and alert on unauthorised deviation from the baseline. |
| 4.13.7 | Automate configuration | Use dedicated tools that configure or reconfigure settings automatically on all information assets, under change management. |
| 4.13.8 | Improve hardening | Keep measuring, reviewing and improving the configuration management and hardening requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.14.1 | Set secure development requirements | Document secure development: coding standards and practices (such as approved libraries and APIs), separated environments with allocated access, and tests that software meets your security requirements. |
| 4.14.2 | Limit access to environments | Allow only authorised staff into each development environment, through identity and access management. |
| 4.14.3 | Code securely | Follow secure coding practices, such as security by design supported by static or dynamic analysis tools, and secure the integration between applications. |
| 4.14.4 | Move software safely | Move software between environments securely and reliably. |
| 4.14.5 | Use trusted components | Use only trusted, up-to-date third-party components in software you develop in house. |
| 4.14.6 | Review code for security | Carry out and document a security review of developed software and source code, for example checking all input. |
| 4.14.7 | Test software for security | Run security tests to verify how far developed software meets your security requirements. |
| 4.14.8 | Improve secure development | Keep measuring, reviewing and improving the secure software development requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.15.1 | Set email and web requirements | Document email and web browser protection using standard security mechanisms. |
| 4.15.2 | Put protection in place | Put email and browser protection in place, such as spam and phishing filters, multi-factor authentication, email backup and archive, and defences against advanced persistent threats and untrusted websites. |
| 4.15.3 | Block unauthorised webmail | Restrict access to unauthorised web-based email services, for example with firewall rules or network URL filters. |
| 4.15.4 | Improve email and web protection | Keep measuring, reviewing and improving the email and web browser protection requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 4.16.1 | Set penetration testing requirements | Document penetration testing: its purpose and overall objectives, and how often tests are done. |
| 4.16.2 | Define the testing process | Define a penetration testing process covering scope and frequency, using standard methods such as grey box or white box testing to find unknown vulnerabilities. |
| 4.16.3 | Use vulnerability reports as input | Depending on the method, use the vulnerability report as an input to guide penetration tests. |
| 4.16.4 | Send results for remediation | Send penetration test reports to the relevant teams to trigger fixes where needed, through patch management. |
| 4.16.5 | Improve penetration testing | Keep measuring, reviewing and improving the penetration testing requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 5.1.1 | Set physical protection requirements | Document physical protection: facilities that host assets, assets and facilities off site, delivery and loading areas, transport of physical assets and protection against environmental threats. |
| 5.1.2 | Define security perimeters | Set security perimeters around facilities that hold information assets, such as offices, rooms, data centres, ground stations and telecommunications processing equipment. |
| 5.1.3 | Use secure zones and storage | Keep physical assets in suitable security zones, and in secure facilities outside operating hours. |
| 5.1.4 | Secure delivery and loading areas | Secure delivery and loading areas that unauthorised people could use to enter the premises, for example by separating incoming and outgoing shipments. |
| 5.1.5 | Guard against environmental and physical threats | Protect assets from environmental threats, hazards and unauthorised access: fire and power failures, cable security and tidiness, operating conditions set by the maker, and CCTV, alarms and sensors. |
| 5.1.6 | Protect assets in transit | Protect physical information assets while they are being transported, taking account of assessed risks and security during movement. |
| 5.1.7 | Improve physical protection | Keep measuring, reviewing and improving the requirements for protecting physical information assets, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 5.2.1 | Set physical access requirements | Document physical access management: authorisation and control of physical access, and monitoring of that access. |
| 5.2.2 | Keep a physical access list | Keep a list of people authorised to enter your facilities and issue them suitable credentials. |
| 5.2.3 | Run physical access management | Run a process to grant and manage access to facilities, for example secure keys. |
| 5.2.4 | Control visitor entry | Set entry controls for visitors, for example security badges and watching for unusual activity. |
| 5.2.5 | Prune the access list | Keep reviewing the list of authorised people and remove anyone who no longer needs access. |
| 5.2.6 | Review physical access logs | Review physical access logs regularly for suspicious activity, as part of logging and monitoring. |
| 5.2.7 | Improve physical access management | Keep measuring, reviewing and improving the physical access management requirements, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 6.1.1 | Set cloud requirements | Document requirements for cloud services: the security expected of the cloud provider, and service level agreements. |
| 6.1.2 | Assess cloud risk first | Assess risk before adopting cloud services, and when relevant laws change, using your risk assessment and information protection requirements. |
| 6.1.3 | Define cloud security requirements | Use the cloud risk assessment and your asset classification to set the security requirements needed to protect confidentiality, integrity and availability of assets in the cloud. |
| 6.1.4 | Agree cloud SLAs | Agree SLAs with the cloud provider covering at least your cloud security requirements, incident notice and recovery duties, termination for breach, and exit steps including secure deletion and return of data in a usable form. |
| 6.1.5 | Host data in Saudi Arabia | Make sure the site where your data is hosted and stored is in the Kingdom of Saudi Arabia. |
| 6.1.6 | Audit the cloud provider | Audit, review and monitor the cloud provider's compliance with the contract. |
| 6.1.7 | Improve cloud security | Keep measuring, reviewing and improving the requirements for cloud services, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| 6.2.1 | Set outsourcing requirements | Document requirements for outsourcing: risk assessment before outsourcing assets, the security expected of the third party, and service level agreements. |
| 6.2.2 | Assess outsourcing risk first | Assess risk before outsourcing any information assets, and when relevant laws change, using your risk assessment and information protection requirements. |
| 6.2.3 | Set third-party security requirements | Use the risk assessment to set the security requirements the provider must meet to protect the outsourced assets, for example non-disclosure clauses. |
| 6.2.4 | Agree outsourcing SLAs | Agree SLAs with the provider covering at least their security requirements, how incidents are communicated, termination for breach and exit steps such as media destruction and encryption. |
| 6.2.5 | Audit the third party | Audit, review and monitor the third-party provider's compliance with the contract. |
| 6.2.6 | Screen third-party staff | Screen third-party personnel who are contracted to work on critical systems. |
| 6.2.7 | Improve outsourcing security | Keep measuring, reviewing and improving the requirements for outsourcing services, along with the process behind it. |
| Ref | Control | What it requires |
|---|---|---|
| Sec. 6, item 1 | Own your cybersecurity | Take full responsibility for your own cybersecurity. |
| Sec. 6, item 2 | Be ready for CST checks | Expect CST to check your compliance through self-assessment, field inspections, compliance workshops and audits, whether planned or triggered by an incident. |
| Sec. 6, item 5 | Apply controls to your compliance target | Apply the requirements and controls in line with the compliance targets CST sets for you. |
| Sec. 6, item 6 | Report compliance on request | Submit compliance reporting, for example a self-assessment or other means, when CST asks. |
| Sec. 6, item 7 | Hand over information on request | Give CST information and documents when it asks, in addition to the reporting the framework already defines. |
Alongside the list above, SecureXcel keeps a unified set of practical controls. For each control the workbook gives the risk it addresses, the objective, a description, whether it is preventive or detective, how often to run it, the design and operating test procedures, and the evidence to collect, with the references it covers in this framework. There is one workbook per framework, supplied as it is, with a Version History sheet for document control. Free account needed; you come straight back to the file.
CST's own. Controls in section 6 are numbered domain, category and control, so 4.7.2 is the second control in the seventh category (identity and access management) of the fourth domain (logical security). The roles lists in sections 5 and 6 are shown as Sec. 5 or Sec. 6 with the item number.
CST marks each control Level 1, 2 or 3. Level 1 is basic controls, Level 2 is advanced requirements and Level 3 is about measuring efficiency and improving the controls from the first two. To reach a level you must meet the levels below it. CST tells each provider its target level and date.
A provider that CST and the NCA classify as critical national infrastructure follows the NCA's Essential Cybersecurity Controls rather than the section 6 list. It also reports incidents to the NCA and CST, and shares risks, alerts and indicators with CST.
For cloud services, control 6.1.5 requires the hosting and storage site of the organisation's data to be in the Kingdom of Saudi Arabia. Check CST's current text and any sector rules that apply to you.
No. It is a plain-English summary in our own words, using CST's reference numbers. The English text is not an official translation, and the Arabic original prevails. Read CST's published framework, and any later version, before you rely on a requirement.