You want to test your security. You hire a penetration tester or a vulnerability assessor. They ask you to define the scope. You are not sure what to include. You list your main website and a few servers. The test happens. The report comes back. It looks good.

But you missed something. An API endpoint you forgot about. A cloud storage bucket you left open. A third-party vendor connection you did not consider.

Your assessment was accurate for what you tested. But it did not cover everything that matters.

A well-defined scope is the most important part of any cybersecurity assessment. Without clear boundaries, you will miss critical vulnerabilities. Or worse, you will disrupt your operations.

Let me show you how to define scope properly so you get an accurate assessment.

Why Scope Matters

Scope defines what is included in the test and what is not. It sets the boundaries for the tester. It tells them where they can look and what they can touch.

A good scope protects your business. It ensures that the tester does not accidentally take down your production systems. It ensures that they do not waste time on low-value targets. It ensures that they focus on what actually matters.

A bad scope leaves gaps. You tested your website but not your API. You tested your servers but not your cloud storage. You tested your internal network but not your third-party vendors.

The gaps are where attackers will find you.

Start with Your Business Priorities

Before you look at any system or application, you need to understand what matters most to your business. The scope of your assessment should directly reflect the risks that could cause the most damage.

Ask yourself these questions:

What are your crown jewels? What systems, databases, or processes need to be protected because, without them, your business will not work? Such may include the payment gateways of a fintech organization, the patients’ data of a healthcare organization, and the customers' data of a retail organization.

Which regulations must be followed? The regulations will be set out in security standards such as PCI DSS, ISO 27001, GDPR, and SOC 2.If you accept credit cards, you must test the systems that handle card data. If you process EU citizen data, you must test the systems that hold that data.

What is your risk appetite? How much risk is your leadership willing to accept? This is important in determining how you will prioritize the systems that need rigorous testing versus those that don’t.

Identify All of Your Assets

You cannot test what you do not know exists. Before you define scope, you need a complete inventory of your IT assets.

What to include:

• Your externally accessible applications. Your websites, web applications, APIs, and mobile applications. They are the most exposed and should be your first target.
• Your internal systems. Your internal networks, servers, workstations, and internal applications. The attackers can access these systems after initial access.
• Your cloud environments. Your cloud accounts, cloud storage buckets, cloud databases, and any other cloud resources. Misconfigured cloud resources are a leading cause of breaches.
• Your third-party vendors. Your vendors who have access to your systems or data. If they are compromised, you are compromised.
• Your IoT and OT devices. Your printers, cameras, sensors, and industrial control systems. These are often overlooked and can be easy entry points for attackers.
• Your sensitive data. Where is your sensitive data stored? Customer data, financial data, intellectual property, employee data. The systems that hold this data should be a priority.

Document Your Attack Surface

Once you have your asset inventory, you need to document your attack surface. The attack surface is all the points where an attacker could enter your environment.

What to document:

• Your IP addresses. All public IP addresses. Include both fixed and dynamic addresses.
• Your domain names. All domains and subdomains. Include those that are not actively used.
• Your open ports. All ports that are open to the internet. Include both well-known and obscure ports.
• Your services. All services that are exposed to the internet. Include both production and test services.
• Your authentication points. All login pages, API authentication endpoints, and single sign-on systems.
• Your third-party connections. All connections to third-party vendors, partners, and customers.

Define the Testing Boundaries

Once you know what you have and where it is, you need to define the boundaries of the test.

What to include:

• The target systems. What specific systems will be tested. This involves IP addresses, domain names, and hostnames.
• What target applications are to be tested. What specific applications will be tested. This includes web applications, APIs, and mobile applications.
• What target networks are to be tested. What specific network segments are being tested.
• The target users. Which specific user roles are included. This includes standard users, administrators, and privileged users.
• The Target Data. What data sets would be tested. This includes customer data, financial data, and intellectual property.

What would be Excluded:

• Systems which are out of scope. Listing systems which would not be included in the test. To avoid testing systems you are not supposed to test.
• Systems that require special care. If a system is critical or fragile, flag it as such. The tester will need to be more careful.

Consider the Testing Type

The type of test you choose will affect your scope.

External penetration testing:

External testing focuses on your external perimeter. This will simulate an attacker that is located outside your network.

Scopes for the external test include all IP addresses on the internet, all domain names and subdomains, all web applications and APIs, all email servers, and all VPNs and remote access endpoints.

Internal penetration testing:

Internal testing tests your internal security. It assumes that the attacker is already inside your network.

Scope for internal testing consists of all internal networks, all internal servers and workstations, all internal applications, all Active Directory and internal authentication systems, and all internal data storage.

Web application testing:

Web application testing involves testing a particular application. This type of testing involves an attack scenario against a targeted application.

Scope of web application testing includes the application, the application API endpoints, backend systems of the application, application authentication and authorization, and data storage within the application.

Cloud security assessment:

The cloud security assessment will be specific to your cloud environment. The cloud security assessment will involve simulating a hacker attacking your cloud environment.

Scopes involved in cloud security assessment include all cloud accounts, all cloud resources and services, all cloud storage, all cloud permissions and IAM roles, and all cloud network configurations.

Consider the Testing Depth

The depth of your test affects your scope.

vulnerability assessment:

A vulnerability assessment is a high-level scan. It identifies known vulnerabilities. It does not exploit them.

Scope for vulnerability assessment includes all target systems, all target applications, all target networks, and all target cloud resources.

Penetration test:

A penetration test is a deeper test. It identifies vulnerabilities and attempts to exploit them. It demonstrates real business impact.

Scope for penetration test includes a subset of target systems, a subset of target applications, a subset of target networks, and a subset of target cloud resources.

Red team engagement:

A red team engagement is a full-scale attack simulation. It uses any means necessary to achieve the objective.

Scope for red team engagement includes the specific objective, the timeline, and the rules of engagement. The target systems are not predefined. The red team finds the weakest entry point.

Consider the Timing

The timing of your test affects your scope.

Testing during business hours:

If you test during business hours, you need to be more careful. The tester has to be careful not to disturb any activities.

Scope of the test:

It is possible to test those systems that can be tested without disturbing any activities during the business hours. Critical systems will be left alone.

Tests performed outside the business hours:

If the tests are performed outside the business hours, then the tester becomes more aggressive. He is free to do more.

Continuous testing:

Continuous testing runs in the background. It is always on.
Scope includes all systems that need continuous monitoring. Alerts are configured for high-risk findings.

Consider the Rules of Engagement

The rules of engagement define how the test will be conducted.

What to define:

• Social engineering. Is the tester allowed to use social engineering? Phishing, vishing, and pretexting are powerful techniques but can be disruptive.
• Physical testing. Is the tester allowed to test physical security? Tailgating, lock picking, and other physical techniques are realistic but intrusive.
• Destructive Testing. Is destructive testing allowed? The deletion or modification of any data is generally not allowed in production systems.
• Third-Party Testing. Is third-party testing allowed? Third-party testing must have the approval of the vendor being tested.
• Timeline for Reporting. How soon must the tester report the findings? Critical information has to be reported immediately.
• Escalation Pathways. In an emergency situation, who should the tester inform?Clear escalation paths prevent confusion.

Document Your Scope

Once you have defined your scope, document it clearly.

What to include:

• An executive summary. A high-level overview of the scope. This is for leadership.
  A detailed technical scope. The IP addresses, domain names, applications, and systems included.
• A list of exclusions. The systems, applications, and networks excluded from the test.
• The testing type. The type of test being performed.
• The testing depth. The depth of the test.
• The timing. The schedule and windows for testing.
• The rules of engagement. The specific rules for the test.
• Sign-off. Signatures of both sides. This indicates that there was agreement on scope.

Practical Case Study: Identifying Scope for a Mid-Sized E-commerce Company

Let me demonstrate it through an example.

Company Overview:

It is a mid-sized e-commerce company which sells products via its own website. It owns a website, mobile app, customer base, payment gateway, and own inventory management system. It also accepts credit card payments, so it should follow PCI DSS standards. Moreover, it stores customer data, so it should follow GDPR requirements.

Step 1: Identify Business Critical Elements

For the company, the business critical elements are customer database and payment gateway. If either is compromised, the business would fail. The company also needs to maintain PCI DSS compliance and GDPR compliance.

Step 2: Identify Assets

The company documents all its assets. Website (www.example.com), Mobile App (iOS and Android versions), Customer Database (AWS RDS), Payments (Stripe integration), Inventory Management (internal server), Email Server (Microsoft 365), Cloud Storage (AWS S3).

Step 3: Identification of the Attack Surface

Documentation regarding the use of the company of its public IP addresses, domains (example.com, api.example.com, admin.example.com), open ports (80, 443, 22), and services (web server, API server, SSH) exists.

Step 4: Identification of the Scope of Testing

All public servers of the company (website, mobile application, API, and email server) will undergo testing. However, testing will not be done on the inventory system because it is not available online.Also, testing would not take place for the AWS S3 storage as it is not publicly available.

Step 5: Selecting Testing Types

In this case, the company will perform both external penetration testing and web application testing. External testing will test the website, API, and email server while web application testing will test the website and mobile app.

Step 6: Testing Depth Selection

In selecting testing depth, the company selects a complete penetration test rather than a vulnerability scan alone. The firm desires to find out if the vulnerabilities discovered can be exploited to access the customer database.

Step 7: Test Timing Definition

The company decides to conduct the test during non-business hours to avoid disruptions. The test will be conducted from 10 PM to 6 AM for three consecutive days.

Step 8: Rules of Engagement

The company prohibits social engineering and physical testing. It requires immediate reporting of any critical findings. The escalation path is the CISO.

Step 9: Document and Sign Off

The company documents all of this in a scope document. Both the CISO and the penetration testing organization provide authorization for this action.

Outcome:

As a result, through the penetration test, it becomes evident that there is a vulnerability in the API allowing an attack on the customer database. The company closes this vulnerability before the hacker does so. This test is quite specific because of its defined scope.

Common Mistakes in Scoping

Mistake 1: Scoping too broadly.

Scoping everything takes time and money, not to mention operational disruption. Concentrate on that which really counts.

Mistake 2: Scoping too narrowly.

Testing too little leaves gaps. Attackers will find the gaps. Include all critical systems and applications.

Mistake 3: Forgetting about third-party vendors.

Your vendors have access to your systems. If they are compromised, you are compromised. Include vendor connections in your scope.

Mistake 4: Forgetting about cloud resources.

Cloud resources often get forgotten. List all your cloud-based services, storage, and databases.

Mistake 5: Overlooking testing windows.

You may not be able to test your system during business hours because of its critical nature. Plan for testing outside business hours.

Mistake 6: Ignoring the rules of engagement.

Without them, the tester will go beyond his mandate. Set the boundaries clearly.

The Bottom Line

Scope definition is the most crucial element of any cybersecurity assessment. It makes sure that the tester concentrates on the most essential things. It gives you an accurate picture of your security posture.

Start with your business priorities. Identify your crown jewels. Document your attack surface. Define your testing boundaries. Consider your testing type and depth. Define your rules of engagement. Document and sign off on your scope.
Do this right, and you will get an accurate assessment. Do it wrong, and you will have gaps.

The attackers will find the gaps. Make sure you find them first.

FAQ Section

What is cybersecurity scope?

Cybersecurity scope includes what is in scope for testing purposes and what is out of scope. The scope is the set of limitations that determine the range within which testing takes place. It informs the tester of what they are allowed to investigate and where they are allowed to do it.

Why is scope important?

The importance of scope is due to the fact that scope allows a tester to focus on relevant targets rather than wasting time on non-relevant targets. Additionally, the scope allows a tester to avoid disrupting the functioning of critical systems.

What should be contained within a scope document?

The scope document should include an executive summary, technical scope in detail (IPs, domains, applications), exclusions, test type, test depth, timing, rules of engagement, and sign-off by both sides.

How can I determine my crown jewels?

Crown jewels are those systems, data sets, or processes that, if taken down, will render your business unable to function. In the case of a fintech firm, the payment gateway is a crown jewel, while in a healthcare organization, patient records are crown jewels.

What is the most common scope mistake?

The most common scope mistake is forgetting about something. Forgetting about third-party vendors. Forgetting about cloud resources. Forgetting about testing windows. A complete asset inventory prevents these mistakes.