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.

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.
| Activity | What it does | Who / how | How often | What you get |
|---|---|---|---|---|
| Vulnerability scanning | Checks servers, websites and libraries against known weaknesses and misconfigurations | Automated tools, run by IT or your provider | Continuously or at least monthly, and after changes | A long list of possible issues, some false positives |
| Vulnerability assessment | Reviews scan results, removes false positives, ranks by risk | A security analyst | Regularly, e.g. quarterly | A prioritised fix list |
| Penetration test | Tries to exploit weaknesses and chain them to reach data or money | Skilled testers, manual work plus tools | Before major launches, after big changes, and periodically | Proven 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?
| Type | What the testers receive | Strength | Limitation |
|---|---|---|---|
| Black box | Only the URL or app name | Shows what a stranger on the internet can do | Much of the time goes on discovery; deep logic flaws are often missed |
| Grey box | User accounts for each role, basic documentation | Best value for most business systems; tests permissions and workflows | Needs preparation of accounts and test data |
| White box | Accounts, architecture and source code | Deepest coverage for the time spent | Requires 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:
- The exact targets: domains, IP addresses, app versions and accounts.
- Start and end dates, allowed hours and blackout periods (for example month-end closing or the Ramadan sales peak).
- Allowed and forbidden techniques: no denial-of-service, no social engineering unless agreed, no real payments.
- Contacts on both sides and a stop procedure if something breaks.
- How test data and any real data seen are handled, stored and deleted.
- 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:
| Rating | CVSS score |
|---|---|
| None | 0.0 |
| Low | 0.1 to 3.9 |
| Medium | 4.0 to 6.9 |
| High | 7.0 to 8.9 |
| Critical | 9.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:
| Factor | Lower effort | Higher effort |
|---|---|---|
| Size of the application | Brochure website, few forms | ERP with many modules, roles and workflows |
| Number of roles | Customer and admin | Cashier, branch manager, accountant, HR, sales rep, admin |
| Platforms | Web only | Web, API, Android and iOS apps |
| Test type | Automated scan with review | Manual grey or white box with code review |
| Environment | Ready staging with test data | Production with restricted windows |
| Deliverables | Technical findings list | Executive 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.
Cybersecurity for Egyptian SMEs: A Practical 90-Day Plan26 September 2026 · 10 min
Ransomware Protection for Egyptian Companies: Prevent, Contain and Recover26 September 2026 · 9 min
Phishing and Fake Payment Requests: Protecting Egyptian Businesses from Email and WhatsApp Scams26 September 2026 · 10 min
