Cybersecurity Assessment Checklist for Saudi Arabia SMBs

A growing Saudi business has reached a familiar decision point. Microsoft 365 supports daily work, employees connect from multiple locations, several business applications sit in the cloud, and a firewall and endpoint security product are already in place. Backups exist somewhere. Different people know different passwords, systems, suppliers, and configurations.

Management decides it is time to outsource part of IT operations or bring in a managed security service provider (MSSP).

Then the prospective provider starts asking questions.

How many endpoints do you have? Which accounts hold administrative privileges? Who owns the Microsoft 365 tenant? What is your recovery point objective? Which firewall rules permit remote access? Where are security logs retained? Which Saudi regulatory requirements apply to the organization?

The problem is often not that nobody knows anything. It is that the answers are fragmented across spreadsheets, consoles, contracts, emails, individual employees, and external vendors.

That makes a cybersecurity readiness assessment valuable before outsourcing begins. The goal is not to make the environment perfect first. It is to establish an accurate current-state picture so the organization and its prospective provider understand what exists, what matters most, who owns it, and where the immediate risks are.

For organizations considering managed services, this cybersecurity assessment checklist for Saudi Arabia provides a practical way to assemble that picture. It forms part of our complete guide to Managed Cybersecurity for GCC SMBs.

An MSP or MSSP cannot manage what neither side can reliably identify.

An incomplete asset inventory can leave endpoints outside monitoring. Unknown administrative accounts can preserve unnecessary privileged access. Unclear backup arrangements can make recovery assumptions unreliable. Forgotten vendor connections can create paths into systems that a new provider does not know exist.

Preparation also helps an SMB evaluate prospective providers. When management understands its own environment, discussions can move beyond "we need better cybersecurity" toward specific requirements: protecting Microsoft 365, monitoring endpoints, improving patch management, centralizing logs, testing recovery, managing vulnerabilities, or establishing incident response processes.

Our guide to getting started with managed IT and cybersecurity provides broader guidance on choosing a starting point and preparing for an engagement. The checklist below focuses specifically on the evidence worth gathering before that assessment or outsourcing process begins.

A useful principle applies throughout: do not hide gaps because they look untidy. An undocumented server or untested backup is exactly the kind of information an assessment needs to surface.

Start with the basic question: what technology does the business depend on?

For each important system, identify an owner. "IT" is not always sufficient. A finance application, for example, can have a technical administrator and a business owner responsible for deciding how critical the application is and who should have access.

Also record end-of-life or unsupported technology. It may not be possible to replace it immediately, but the incoming provider needs to know it exists.

Not every device deserves the same priority.

Ask what would prevent the company from serving customers, collecting revenue, paying employees, communicating, or meeting contractual obligations if it disappeared tomorrow.

Mark those applications and systems as critical. Record their dependencies where possible. A business application may depend on identity services, DNS, a database, internet connectivity, cloud infrastructure, and a third-party integration. Those dependencies matter when assessing both security and resilience.

Identity is one of the first areas an MSSP assessment should examine because compromise of an account can provide access to multiple business systems, depending on its privileges and integrations.

Produce a list of active users and compare it with actual employees, contractors, consultants, service accounts, shared accounts, and former personnel.

Then distinguish ordinary users from privileged users.

Record whether administrators use separate privileged accounts or their ordinary email accounts for administration.

Also document multifactor authentication (MFA) coverage. Do not simply record that "MFA is enabled." Determine which users, administrators, applications, and access paths are actually protected, and identify exceptions.

Pay particular attention to shared credentials, dormant administrator accounts, legacy authentication, service accounts with unclear ownership, and accounts belonging to former employees or suppliers.

This gives the prospective provider a more useful starting point for identity protection and Zero Trust than a simple user count.

A network diagram does not need to be an architectural masterpiece. It needs to be accurate enough to explain how systems communicate.

Document offices, branches, internet connections, firewalls, routers, switches, wireless networks, VPNs, server networks, cloud connections, and important network segments.

Then identify pathways into the environment.

During an assessment, it is possible to find connections that had a legitimate historical reason to exist but no longer have a clearly documented owner or business requirement.

The objective at this stage is not to delete anything indiscriminately. It is to establish what exists, why it exists, and who can confirm whether it is still required.

Cloud adoption changes the assessment, but it does not eliminate the need for one.

For Microsoft 365, gather information on licensing, tenant administration, Entra ID configuration, MFA, administrative roles, email security, sharing, endpoint management, and any deployed Microsoft security capabilities.

For Azure, AWS, or other infrastructure platforms, identify subscriptions or accounts, workloads, privileged access, logging, network controls, public-facing resources, and the people or providers responsible for them.

Do the same for SaaS. HR, accounting, customer relationship management, document sharing, project management, and other SaaS platforms can hold sensitive business or personal data even though no server is present in the office.

Record who owns each service, who administers it, how authentication works, what data it contains, and whether logs can be obtained.

Cloud responsibilities also matter under applicable Saudi cybersecurity frameworks. The National Cybersecurity Authority's current Essential Cybersecurity Controls (ECC 2-2024) include controls concerning cloud computing and hosting for organizations within their scope, and the NCA publishes related implementation guidance.

Now inventory the controls already protecting the organization.

This is more useful than beginning with a shopping list of new security products. An SMB may already own useful capabilities through existing endpoint, firewall, Microsoft, cloud, or backup subscriptions without having deployed them completely.

For each tool, establish the scope rather than merely recording its name.

If an endpoint platform reports 137 protected devices while the asset inventory contains 164 active endpoints, the missing 27 deserve attention. If important cloud audit logs exist but nobody collects or reviews them, the presence of logging alone does not provide effective monitoring.

Gather recent vulnerability scan results if they exist.

Document how operating systems, third-party applications, servers, network equipment, and other infrastructure receive updates. Identify devices that cannot currently be patched and systems that are already outside vendor support.

The provider should also understand how vulnerabilities are prioritized and remediated. A scan that continuously produces findings without clear ownership, priorities, or remediation tracking offers limited risk reduction. Our approach to vulnerability prioritization beyond CVSS explains how to focus remediation where it matters.

Security monitoring depends on evidence.

List the logs currently available from identity platforms, endpoints, servers, firewalls, Microsoft 365, cloud platforms, VPNs, critical applications, and other security systems.

If the organization already has SIEM, XDR, or security operations center (SOC) services, document the integration coverage rather than assuming "the SOC monitors everything."

This is an important distinction for outsourcing. A provider cannot investigate activity that was never logged or otherwise made available for analysis.

Cyberactics' managed cybersecurity services include areas such as managed detection and response, SIEM, EDR, vulnerability management, and incident response. These capabilities depend on establishing appropriate visibility rather than treating monitoring as a black box.

One of the most important questions in an IT security assessment checklist is deceptively simple: can the business restore what it needs?

List what is backed up, including servers, databases, file repositories, cloud workloads, application data, and relevant SaaS environments. Then document where those backups reside, how long they are retained, who administers them, and how access is protected.

These targets should come from business impact rather than arbitrary technical settings.

Most importantly, gather evidence of restore testing.

A dashboard showing successful backup jobs provides evidence that backup jobs completed. A successful recovery test provides much stronger evidence that the organization can restore and use the protected data when it matters.

Previous security incidents contain valuable information about the environment.

Collect records of ransomware, phishing compromises, business email compromise, malware infections, lost devices, unauthorized account access, data exposure, denial-of-service events, and other material security incidents.

Include near misses where they revealed weaknesses.

For each incident, identify what happened, which assets were affected, how the organization detected it, how access was contained, whether credentials were reset, and what corrective actions followed.

Do not limit this exercise to formal incident reports. Smaller organizations may have significant historical knowledge in email threads, help-desk tickets, or individual employees' memories.

Capturing it before an outsourcing transition prevents useful security context from disappearing.

For a Saudi SMB, "Are we compliant with NCA?" is too broad a starting question.

Regulatory scope should be established carefully based on the organization's sector, activities, systems, data, customers, ownership, and contractual requirements.

The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC 2-2024) apply to Saudi government agencies and their affiliated companies and entities, including affiliated companies and entities inside and outside the Kingdom, as well as private-sector entities that own, operate, or host Critical National Infrastructure. The NCA strongly encourages other organizations in the Kingdom to leverage the controls as cybersecurity best practice.

This distinction matters. A private Saudi SMB should not automatically claim that the ECC is mandatory simply because it operates in the Kingdom. Its specific regulatory and contractual scope needs to be determined.

The NCA also provides implementation guides for its cybersecurity controls, which can help organizations within the relevant scope understand how requirements translate into practical implementation.

Organizations processing personal data within the scope of Saudi Arabia's Personal Data Protection Law (PDPL) should separately consider the PDPL and its Implementing Regulations.

SDAIA's official guidance for controllers and processors explains the roles of controllers and processors. This becomes particularly relevant when an outsourced provider processes personal data on behalf of the customer.

The PDPL Implementing Regulations require controllers to ensure that selected processors provide sufficient guarantees to protect personal data and that processor agreements address matters including the processing purpose, categories of personal data, duration, breach notification, and subcontractors. Saudi data-protection requirements also require appropriate organizational, administrative, and technical measures to protect personal data.

Before outsourcing, therefore, identify the personal data that could become accessible to the provider and determine the provider's role and responsibilities rather than treating the outsourcing contract as solely an IT procurement exercise.

Sector-specific requirements may also apply. Regulatory applicability should be confirmed for the individual organization rather than inferred from a generic checklist.

Technology tells only part of the story. Documentation establishes responsibilities.

Before the assessment, collect available cybersecurity and IT policies covering subjects such as acceptable use, access management, passwords, remote working, backups, incident response, business continuity, data handling, and change management.

Do not create policies retrospectively just to fill the folder.

If a policy is missing or obsolete, record that as a finding. An accurate gap is more useful than a document that says controls exist when operating practices tell a different story.

This helps expose dependencies and clarify where responsibility changes hands.

Every important system should answer four questions:

Who owns the business requirement? Who administers the technology? Who supports it externally? Who makes decisions during an incident?

Those answers are particularly important during an MSP transition.

One supplier may manage the firewall, another the ERP system, an internal employee may control Microsoft 365, and a former consultant may still control a domain registrar account. Without an ownership map, apparently simple changes can become operational risks.

Document escalation contacts and approval authority as well.

The provider needs to know not only who can technically make a change, but who is authorized to approve a potentially disruptive action during an incident.

By this stage, the SMB should have enough material to create a practical pre-engagement package.

That package does not need to be a single enormous document. A controlled repository containing current inventories, diagrams, reports, policies, configurations, contracts, recovery information, and responsibility records is often more useful.

At minimum, the assessment should give the prospective MSP or MSSP a reliable view of users and identities, administrative accounts, devices, networks, cloud services, firewalls and VPNs, backups and RTO/RPO, critical applications, vulnerabilities and patching, security tools, logs and SIEM coverage, vendors and contracts, policies, previous incidents, regulatory scope, and technical ownership.

Handle the package as sensitive information. Network diagrams, privileged-account lists, vulnerabilities, configuration exports, and security architecture can themselves be valuable to an attacker.

Use secure methods agreed with the provider for transferring and storing assessment evidence. Do not send administrator passwords or other secrets simply because a provider has requested general onboarding information.

The assessment should work in both directions.

The provider is examining your environment, but your organization should also establish exactly what the provider will manage, monitor, and be accountable for.

The aim is not to generate as many contractual clauses as possible. It is to eliminate ambiguous responsibility.

"Managed security" can mean different things to different providers. The scope should explain what is monitored, what is managed, what receives a response, and what remains the customer's responsibility.

Although this checklist is Saudi-first, the operational problem is familiar across the GCC and wider MENA region.

Organizations in Saudi Arabia, the UAE, and Oman can depend on combinations of cloud services, Microsoft 365, remote access, SaaS platforms, local infrastructure, external IT suppliers, and specialized security technologies. Outsourcing one component does not automatically transfer responsibility for all the others.

The regulatory details also differ between countries and sectors. A Saudi requirement should not be assumed to apply in the UAE or Oman, and vice versa. GCC organizations operating across borders should map systems, data, providers, and legal entities to the relevant jurisdictions before translating a cybersecurity framework into compliance obligations.

For businesses that have completed their current-state assessment and need a longer improvement sequence, our GCC Cybersecurity Roadmap for SMEs provides a complementary 12-month approach. The distinction is useful: the assessment establishes where you are today, while the roadmap helps organize what to improve next.

Do not expect the assessment to produce a perfectly clean environment. Its purpose is to expose priorities.

A useful output separates findings according to business risk and urgency. Critical exposures may require action before managed-service onboarding proceeds. Other improvements can become part of a staged security roadmap.

The sequence might involve closing uncontrolled external access, securing privileged identities, extending endpoint coverage, resolving unsupported systems, correcting backup weaknesses, centralizing important logs, improving vulnerability management, or documenting incident-response responsibilities.

Only after the current state is understood does it make sense to decide which capabilities should remain internal and which should be outsourced.

That distinction can prevent a common outsourcing mistake: transferring operational responsibility without first defining the systems, risks, dependencies, and expectations being transferred.

A Saudi SMB does not need enterprise-scale documentation before speaking with an MSP or MSSP.

It does need enough evidence to answer fundamental questions about its assets, identities, infrastructure, cloud services, security controls, logs, backups, vendors, incidents, regulatory scope, and ownership.

Where the answers are incomplete, record the gaps. Those gaps are part of the assessment.

A good cybersecurity assessment turns "we think this is covered" into a verifiable current-state picture. It gives management a better basis for comparing providers, gives technical teams clearer priorities, and gives the chosen provider a safer starting point for assuming responsibility. If your organization is preparing for that step, get in touch to discuss your environment.