THE TEST IS THE EASY PART. THE REMEDIATION ARCHITECTURE IS WHERE THE VALUE IS.
What we do, and what we do not deliver
We do not perform penetration testing. PRAECEPTA does not deliver penetration tests, red team engagements or vulnerability scanning. Testing is delivered by specialist providers holding the appropriate accreditations for the jurisdiction — in Dubai, that includes CREST accreditation requirements for relevant service areas.
What we do is the layer above and below the test.
Above: scoping and methodology design. Defining what should be tested, to what depth, against which threat model, with what rules of engagement and success criteria — so that the test answers a question worth asking.
Below: findings review and remediation architecture. Taking a test report and converting it into root-cause analysis, architectural remediation and a sequenced plan — rather than a ticket queue.
We maintain relationships with accredited testing providers and will introduce you. We take no commission on that introduction, and we will say so in writing.
The problem
Most penetration test reports are technically competent and architecturally useless.
They arrive as a list — forty-seven findings, rated critical to informational, each with a description and a remediation note. The organisation works down the list, closes what it can, accepts the rest, and repeats the exercise twelve months later with a substantially similar list.
Two things go wrong. First, the scope was never designed against a threat model, so the test answered a technical question rather than a business one. Second, the findings were never analysed for root cause, so the organisation is remediating symptoms while the underlying architectural weakness persists.
Twelve individual findings caused by one absent architectural control are not twelve problems. They are one problem, presented twelve times — and closing them individually guarantees they return.
OUR APPROACH
-
Design the scope against a threat model, not an asset list. Which threat actors are relevant to this organisation, what would they realistically target, and what would constitute a material outcome. Scoping from a threat model produces a test that answers something the board cares about.
-
Define depth, methodology and rules of engagement. Black box, grey box or white box. Which methodology — PTES for the overall process, OWASP WSTG v4.2 for web applications, and the relevant standards for cloud, mobile and infrastructure. Testing windows, escalation paths, out-of-scope systems, and the conditions under which testing stops.
-
Specify the deliverable before the test starts. What the report must contain to be useful: root-cause attribution, exploitation narrative, business impact, and remediation at design level rather than configuration level. Specifying the output is the single highest-leverage act in the whole process, and almost nobody does it.
-
Support provider selection. Requirements, evaluation criteria, accreditation verification, and technical evaluation of proposals. We assess methodology quality and reporting standard — the two things that most differentiate providers and that procurement processes rarely test.
-
Review the findings for root cause. Cluster findings by underlying architectural cause. Twelve access-control findings across four applications are usually one identity architecture problem. This is the analysis that converts a test into a programme.
-
Produce remediation architecture, sequenced by dependency. Design-level remediation with owners, effort estimates and dependencies. Where a finding maps to a control requirement in a framework you report against, we note it — so remediation serves your assessment cycle as well as your risk position.
ENGAGEMENTS
VA-01 Test Scoping & Methodology Design
Typical duration: 4-8 days
Threat-model-based scope, depth specification, methodology selection, rules of engagement, deliverable specification
VA-02 Provider Selection Support
Typical duration: 3-6 days
Requirements, evaluation criteria, accreditation verification, technical proposal evaluation
VA-03 Findings Review & Root Cause Analysis
Typical duration: 3-7 days
Independent review of a test report, root-cause clustering, architectural gap identification
VA-04 Remediation Architecture & Roadmap
Typical duration: 8-15 days
Design-level remediation, dependency sequencing, framework control mapping
VA-05 Annual Testing Programme Design
Typical duration: 6-10 days
Multi-year testing strategy, scope rotation, coverage model, provider panel structure
VA-06 Post-Test Board Briefing
Typical duration: 2-4 days
Findings translated into risk and investment terms, quantified where material using Open FAIR
METHODOLOGIES REFERENCED
PTES — Penetration Testing Execution Standard · OWASP Web Security Testing Guide v4.2 · OWASP Top 10 for LLM Applications and MITRE ATLAS for AI system testing · MITRE ATT&CK for threat modelling and coverage mapping · STRIDE and PASTA for threat modelling
Authorisation and scope
All testing activity must be authorised in writing by the system owner before it begins, and conducted within a defined, agreed scope.
PRAECEPTA does not perform testing. Where we design a scope, that scope becomes the basis of the authorisation your provider requires. Where we review findings, we work from a report produced under an existing authorised engagement.
We do not accept engagements involving unauthorised access to any system, and we do not review findings from testing we have reason to believe was unauthorised.