Security

Penetration Testing vs Vulnerability Scanning: What Egyptian Companies Should Ask For

Scanning, vulnerability assessment and penetration testing are not the same thing. Learn how to scope a test, what written authorisation Egyptian law requires, how to read CVSS 4.0 scores and reports, and what drives the cost.

Illustration of a tester's report with severity ratings beside a shielded ERP dashboard and a signed authorisation letter

Your ERP holds every invoice, your online store holds customer addresses, and your mobile app talks to both through an API. Sooner or later a bank, a large client or an auditor asks: "Has this been tested?" Many Egyptian companies then order "a pentest" without knowing what they are buying.

The short answer: a vulnerability scan is an automated check for known weaknesses that you should run often; a vulnerability assessment reviews and prioritises those findings; a penetration test is a time-boxed exercise in which skilled testers try to break in the way an attacker would, to prove what is really exploitable. You need the first two continuously and the third at key moments. This guide explains the difference, how to scope a test, what written authorisation you need under Egyptian law, how to read the report and CVSS scores, and what drives the cost.

Key takeaways

  • Scanning finds known issues cheaply and often; penetration testing proves impact and validates your whole vulnerability management process.
  • Scope decides value: name the systems, user roles, environments and test type (black, grey or white box) in writing.
  • Always sign a written authorisation before any test. Unauthorised access is a crime under Egypt's Law 175 of 2018, even when the intention is good.
  • Read severity (CVSS 4.0) together with business impact; a "medium" finding in your payments flow can matter more than a "high" on a test server.
  • A test is not finished until the fixes are retested and the regression checks are added to your development pipeline.

Scanning, assessment and penetration testing: the difference

The UK National Cyber Security Centre (NCSC) defines penetration testing as "a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system's security, using the same tools and techniques as an adversary might" (NCSC penetration testing guidance). The same guidance makes a point many buyers miss: a pentest should validate your vulnerability assessment and management process, not be the main way you find vulnerabilities. NCSC compares it to a financial audit, which checks the work your internal team does all year.

The US standards body NIST covers the full family of techniques, from reviews and scanning to penetration testing, in SP 800-115, Technical Guide to Information Security Testing and Assessment, published in 2008 and still active.

ActivityWhat it doesWho / howHow oftenWhat you get
Vulnerability scanningChecks servers, websites and libraries against known weaknesses and misconfigurationsAutomated tools, run by IT or your providerContinuously or at least monthly, and after changesA long list of possible issues, some false positives
Vulnerability assessmentReviews scan results, removes false positives, ranks by riskA security analystRegularly, e.g. quarterlyA prioritised fix list
Penetration testTries to exploit weaknesses and chain them to reach data or moneySkilled testers, manual work plus toolsBefore major launches, after big changes, and periodicallyProven attack paths, business impact, fix advice

Why this matters now

Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities was the top initial access vector, at 31% of breaches, ahead of stolen credentials for the first time in the report's 19 years. The same report says only 26% of critical vulnerabilities were fully remediated in 2025. Finding weaknesses is not the hard part; fixing and verifying them is. That is exactly what a good testing programme is for.

How to scope a test that is worth paying for

NCSC recommends that scoping involves the risk owners, technical staff who know the system and a representative of the test team, and that it produces a document stating the technical boundaries and the types of test expected. In practice, answer these questions before asking for quotes:

  • Which systems? Public website, online store, ERP or CRM web app, mobile app and its API, internal office network, cloud accounts, branch Wi-Fi.
  • Which user roles? For an ERP used by a distributor in the Delta, the interesting tests are often "can a sales rep see another rep's customers?" or "can a branch cashier approve a refund?". Provide one test account per role.
  • Which environment? A staging copy with realistic but not real data is safer. If production must be tested, agree time windows and exclusions such as mass emails or real payments.
  • Which integrations are out of scope? Payment gateways, the ETA e-invoice system and courier APIs belong to third parties; testers must not attack them. Test your side of the integration only.
  • What is the goal? For example: "Can an employee change a supplier's bank account without approval?"

Black, grey or white box?

TypeWhat the testers receiveStrengthLimitation
Black boxOnly the URL or app nameShows what a stranger on the internet can doMuch of the time goes on discovery; deep logic flaws are often missed
Grey boxUser accounts for each role, basic documentationBest value for most business systems; tests permissions and workflowsNeeds preparation of accounts and test data
White boxAccounts, architecture and source codeDeepest coverage for the time spentRequires sharing code under a confidentiality agreement

For a custom ERP, CRM or clinic system, grey box is usually the sensible default because most serious issues in business software are about who can see or do what.

Standards to name in the contract

Asking for "a full pentest" invites vague results. Instead, name the methodology and the verification standard:

  • OWASP Web Security Testing Guide (WSTG): the current stable version is v4.2 (released December 2020), with v5.0 in development, according to the OWASP WSTG project page. It is the checklist most web testers follow.
  • OWASP ASVS 5.0.0: the Application Security Verification Standard, dated May 2025 per the OWASP ASVS repository. It lists requirements you can use as acceptance criteria for your developers and testers.
  • OWASP Top 10 (2025 edition) for web apps and the OWASP API Security Top 10 (2023) for APIs as minimum coverage. Our guides to the OWASP Top 10 for business owners and API security for mobile apps and integrations explain each item.

Written authorisation: the legal step you cannot skip

Egypt's Anti-Cyber and Information Technology Crimes Law No. 175 of 2018 punishes intentionally accessing a website, private account or information system without right with at least one year's imprisonment and/or a fine of EGP 50,000 to 100,000 (Art. 14), and exceeding authorised access in time or level with at least six months and/or EGP 30,000 to 50,000 (Art. 15), according to the Andersen English translation of the law. A tester without clear written permission, or one who goes beyond the agreed scope or dates, can fall under these articles. Our explainer on Law 175 of 2018 for companies covers the law in more detail.

A signed "rules of engagement" letter should state:

  1. The exact targets: domains, IP addresses, app versions and accounts.
  2. Start and end dates, allowed hours and blackout periods (for example month-end closing or the Ramadan sales peak).
  3. Allowed and forbidden techniques: no denial-of-service, no social engineering unless agreed, no real payments.
  4. Contacts on both sides and a stop procedure if something breaks.
  5. How test data and any real data seen are handled, stored and deleted.
  6. Permission from third parties where needed, for example a hosting provider or the software vendor if they, not you, operate the system.

The National Telecommunications Regulatory Authority publishes an official list of licensed and accredited cybersecurity service providers; checking it is a reasonable step when you choose an external firm.

How to read a penetration test report

NCSC says a report should include the security issues found, the testers' assessment of the level of risk, a method of resolving each issue, and an opinion on the accuracy of your own vulnerability assessment. Ask for an executive summary and reproducible steps for developers.

Understanding CVSS 4.0 severity

Most reports rate findings with the Common Vulnerability Scoring System. FIRST published CVSS version 4.0 in November 2023. Its qualitative scale is:

RatingCVSS score
None0.0
Low0.1 to 3.9
Medium4.0 to 6.9
High7.0 to 8.9
Critical9.0 to 10.0

CVSS 4.0 has Base, Threat, Environmental and Supplemental metric groups. The specification advises enriching Base scores with Threat and Environmental values for your own systems, because CVSS measures severity, not your business risk. Regulatory exposure, customer impact and financial loss are for you to weigh.

An example finding, translated for management

Imagine a building-materials distributor in Alexandria. The report shows: "Broken object level authorisation on /api/invoices/{id}; CVSS 4.0 High." In plain language: a logged-in sales rep can open any invoice by changing a number in the address, including other branches' customers and prices. The business impact is leaked customer lists and pricing, plus possible personal data exposure under the data protection law. The fix is a server-side ownership check on every request, and the retest proves it.

Prioritise by impact, not by colour

  • Fix first: anything that exposes personal data, money flows (refunds, supplier bank details, discounts) or admin access.
  • Next: issues on internet-facing systems, even if rated medium.
  • Then: hardening items such as missing headers, covered in our pre-launch website security checklist.
  • Record accepted risks in writing with an owner and a review date. NCSC is clear that decisions on fixes are your responsibility.

Retesting and how often to test

A pentest only covers known issues on the day of the test, as NCSC notes, and it is common for a year or more to pass between tests, leaving gaps. A practical rhythm for an Egyptian SME or mid-size company:

  • Continuous: automated dependency and server scanning, patching of internet-facing systems.
  • Every release: automated tests that check permissions. When a pentest finds a flaw, the developers add a test that would fail if it returned, for example with a test runner such as Vitest.
  • Before launch and after major changes: a new payment method, a mobile app, a new customer portal or a move to the cloud.
  • Periodically: a grey-box test of core systems, commonly once a year, or more often where contracts or regulators require it.
  • After every test: a retest of fixed findings within an agreed period, included in the original price.

What drives the cost of a penetration test

We do not publish price ranges because quotes depend heavily on scope. These factors drive the effort:

FactorLower effortHigher effort
Size of the applicationBrochure website, few formsERP with many modules, roles and workflows
Number of rolesCustomer and adminCashier, branch manager, accountant, HR, sales rep, admin
PlatformsWeb onlyWeb, API, Android and iOS apps
Test typeAutomated scan with reviewManual grey or white box with code review
EnvironmentReady staging with test dataProduction with restricted windows
DeliverablesTechnical findings listExecutive summary, CVSS 4.0 vectors, retest and debrief meeting

Be wary of a very low quote for a large ERP: it is usually an automated scan presented as a pentest. Ask how many tester-days are planned, what share is manual, whether a retest is included, and for a sample report with sensitive details removed.

How Nilex helps

Nilex builds business systems with testing in mind: role-based permissions checked on the server, input validation, security headers, rate limiting and audit logs, with automated tests that guard fixed issues. For systems we build or maintain, we prepare staging environments and test accounts per role for your chosen testers, fix findings and support retests. We do not claim to replace an independent tester; we make your system easier to test and quicker to fix. See how we work and our software services.

Frequently asked questions

What is the difference between a penetration test and a vulnerability scan?

A scan is automated and lists known weaknesses; it is cheap enough to run often. A penetration test is manual work in which testers try to exploit weaknesses and chain them to reach data or money. The scan tells you what might be wrong; the test shows what an attacker can actually do.

How often should a company in Egypt do a penetration test?

There is no single legal frequency for most private companies. A common practice is a test before launching a new system, after major changes and periodically, often yearly, with continuous scanning in between. Contracts with large clients or sector rules may require more.

Is it legal to hire someone to hack our own website?

Yes, when the owner of the systems gives clear written authorisation and the tester stays within the agreed scope. Access without right or beyond authorised limits is a crime under Articles 14 and 15 of Law 175 of 2018, so the signed rules of engagement protect both sides.

What does a CVSS score of 9.0 mean?

Under CVSS 4.0, scores from 9.0 to 10.0 are rated Critical. Treat such findings as urgent, but still judge them against your context: where the system sits, what data it holds and whether the flaw is reachable from the internet.

Should we test on the live system or a copy?

A staging copy with realistic test data is safer and lets testers go deeper. Test production only for things that differ there, such as server configuration, within agreed hours and with a stop procedure.

Planning a test for your ERP, store or app, or need help fixing the findings from one? Book a free consultation through our contact page and we will help you scope it properly.

LET'S BUILD

YOUR VISION.
OUR TECHNOLOGY.

Tell us what your business needs. We'll build the system around it.

START A CONVERSATION →

or email us at info@nilexdigitalsystems.com