CyberFortify runs human-led, manual penetration tests — not scanner output with a logo on it. Our methodology is mapped to the recognised standards: PTES, the OWASP Testing Guide (plus ASVS and MASTG for applications), NIST SP 800-115, OSSTMM, and MITRE ATT&CK for adversary techniques. Every engagement runs through seven phases from scoping to retest, every material finding is manually validated and exploited to prove real impact, and every finding is reported with severity, business-risk context, a working proof of concept, step-by-step remediation, and a mapping to the exact compliance control — CBB, SAMA, NCA ECC, PCI DSS, SOC 2 or ISO 27001 — your assessor expects. Retesting is included, so the report evidences closure, not just risk.
// 01 Our testing philosophy
A penetration test is only worth commissioning if a skilled human does the work. Automated scanners are fast and useful for coverage, but they cannot reason about your application's logic, chain several minor issues into a serious attack path, or tell the difference between a theoretical flaw and one that actually exposes customer data. The vulnerabilities that cause real breaches — broken access control, business-logic abuse, authorisation flaws in APIs — are precisely the ones scanners miss, because every request looks valid.
So our work is human-led by design. Tools support discovery and coverage; a security professional does the analysis, validation and exploitation. Every finding we report has been confirmed by a person and demonstrated with a working proof of concept. That is the line between a vulnerability scan and a penetration test, and we do not blur it.
// 02 The standards our methodology maps to
We do not invent methodology; we apply the industry's established standards, which is what lets our reports stand up to an auditor, a QSA or a regulator. Each engagement draws on the appropriate combination:
PTES (Penetration Testing Execution Standard): the overall engagement structure — from pre-engagement scoping through to reporting.
OWASP Testing Guide, ASVS & MASTG: the definitive references for web application, verification-standard and mobile application testing respectively.
NIST SP 800-115: the US federal technical guide to information security testing and assessment — frequently required by compliance regimes.
OSSTMM: the Open Source Security Testing Methodology Manual, for operational and network-level rigour.
MITRE ATT&CK: the adversary tactics and techniques knowledge base — we map findings and red-team activity to ATT&CK so defenders can act on them.
For GCC engagements we additionally map findings to the regulator's own control references — CBB, SAMA and NCA ECC — so the deliverable doubles as compliance evidence.
// 03 Our engagement phases
Every engagement moves through the same seven phases, scaled to the scope. The structure is deliberate: it ensures nothing is missed, and it gives you predictable checkpoints from kickoff to closure.
Scoping & rules of engagement
Agree targets, testing windows, methodology depth, escalation path and stop conditions before any testing starts.
Reconnaissance & enumeration
Map the real attack surface — hosts, services, applications, endpoints and technologies — often finding assets you did not know were exposed.
Vulnerability analysis
Automated tooling plus manual analysis to identify weaknesses, each one validated to remove false positives.
Exploitation
Manually exploit confirmed vulnerabilities to prove real impact and chain them into attack paths a scanner would never assemble.
Post-exploitation
Assess how far an attacker could go — privilege escalation, lateral movement, data access — within agreed limits.
Reporting
Findings with severity, business risk, proof of concept, remediation guidance and compliance-control mapping.
Retest
Verify remediation worked, so closure can be evidenced to an auditor or board — included, not billed separately.
// 04 How we rate and report findings
A finding is only useful if the reader knows how much it matters and exactly what to do about it. We rate every finding on two axes, not one: technical severity (using CVSS) and business risk (what it actually exposes, given the asset's exposure and criticality). An unauthenticated flaw on an internet-facing payment page and the same flaw on an isolated internal box carry the same CVSS but very different business risk, and we say so.
Severity + business-risk context
CVSS score alongside a plain statement of what the issue exposes and why it matters to your organisation specifically.
Working proof of concept
Evidence that the issue is real and exploitable — not a theoretical scanner alert.
Step-by-step remediation
Specific, actionable guidance your engineers can implement, ordered by priority.
Compliance-control mapping
Each finding tied to the relevant CBB, SAMA, ECC, PCI, SOC 2 or ISO control, so the report is audit evidence.
// 05 What makes a CyberFortify finding different
The gap between security testing and audit evidence is where most reports fall down: a technical team produces a list of vulnerabilities, and the compliance team then spends weeks translating it into something a regulator will accept. We close that gap by design. Because every finding already carries business-risk context and a compliance-control mapping, and because retesting is included so closure can be evidenced, our report is structured to serve directly as the assurance your auditor, QSA or supervisor needs — while remaining the actionable technical document your engineers need. One deliverable, two audiences, no translation.
// 06 Frequently asked questions
What methodology does CyberFortify follow?
A human-led, manual methodology aligned to PTES, the OWASP Testing Guide, ASVS and MASTG, NIST SP 800-115, OSSTMM and MITRE ATT&CK. Tooling supports the work; it never replaces manual testing.
Is your testing manual or automated?
Human-led and manual. Scanners assist with coverage, but every material finding is manually validated and exploited — which is how we find the access-control and business-logic flaws scanners miss.
Do your reports map to compliance frameworks?
Yes — every finding is mapped to the relevant control (CBB, SAMA, NCA ECC, PCI DSS, SOC 2, ISO 27001), so the report is audit evidence, with severity, business risk, proof of concept and remediation.
Is retesting included?
Yes. Remediation retesting is part of the engagement, so the final report evidences closure rather than just listing open risks.
// 07 Standards referenced
- PTES — Penetration Testing Execution Standard.
- OWASP Testing Guide, OWASP ASVS, OWASP MASTG — application security testing.
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment.
- OSSTMM — Open Source Security Testing Methodology Manual.
- MITRE ATT&CK — adversary tactics and techniques knowledge base.