Methodology
How we work — and why the report is the product.
A senior-led engagement lifecycle built on cited standards, peer-reviewed before delivery, and finished with the HackingByte Engagement Brief.
- Senior-led delivery.
- Vendor-independent.
- Evidence-driven reporting.
Our published penetration testing and security assessment methodology — what we do at each stage, the standards we follow, the evidence we collect, and how the report is built so it can be read by your engineers, your leadership, and your board.
The engagement lifecycle.
What happens at each stage.
The six stages, in public detail.
-
01 — Scoping
We start with a senior-led scoping call to establish the actual trigger (an upcoming audit, a customer-security questionnaire, a recent cloud migration, a deal under diligence, a regulator-driven scope) and the asset surface in scope. We agree the engagement type, the standards the work will reference, the rules of engagement (testing windows, blast-radius limits, escalation contacts), and the success criteria — the form the final report needs to take for the people who will read it.
-
02 — Kickoff
Kickoff confirms access (cloud read-only credentials, network reachability, test accounts, change-management windows) and aligns escalation paths for critical findings. The team that runs the engagement is the team that scoped it — senior practitioners only, no junior hand-off — and the founder owns the engagement end-to-end. We confirm the inventory of assets, environments, and constraints so the work that follows is grounded in what your business actually runs.
-
03 — Execution
Execution is hypothesis-driven and manual where it matters. For application security work we follow OWASP WSTG and the OWASP API Security Top 10. For network and cloud surfaces we work from PTES, NIST SP 800-115, and CIS Benchmarks. For red team engagements we model adversary behaviour using MITRE ATT&CK. Tools accelerate; senior judgment decides what counts as a finding. We do not run a scan-and-paste pipeline — automated output is verified by hand before it appears in any report.
-
04 — Reporting
Reporting is the product. Every finding is documented with the evidence to reproduce it (request/response snapshots, traffic captures, command transcripts, screenshots), the affected components, the business impact, and the recommended remediation. The first draft is peer-reviewed against the standards matrix before it leaves the firm; the founder personally reviews the executive surfaces. The output is the Three-Artifact Engagement Brief — see the reporting model below.
-
05 — Debrief
The debrief call is a working session with the report on screen — engineering walks through the technical findings, leadership walks through the Executive Risk Brief, and we agree the priority order of the Action Plan together. This is when business-impact context lands: a high-CVSS finding that has no real exploitability path is downgraded; a medium-CVSS finding that breaks a customer-security commitment is raised.
-
06 — Closure
Closure covers retest scope (which findings are retested and on what timeline), evidence retention (engagement evidence is kept under our standard retention policy and is destroyed on request), and the open advisory channel that stays available for follow-up questions. For ongoing retainers we transition into the recurring cadence agreed at scoping — typically monthly review and quarterly reassessment, complemented by our continuous-monitoring platforms.
Standards we build on.
- PTES
- OWASP
- MITRE ATT&CK
- ISO 27005
- NIST
Applied by senior practitioners, not followed as a script.
How each standard applies.
We cite the standards each piece of work draws from — not as a checklist, but so you can audit the methodology end-to-end.
- PTES (Penetration Testing Execution Standard)
- Governs the lifecycle of network and infrastructure penetration testing — pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, reporting.
- OWASP WSTG (Web Security Testing Guide)
- The body of application-security tests we work from on web pen tests — authentication, session management, access control, business-logic flaws, input validation, and the rest of the WSTG checklist.
- OWASP API Security Top 10
- The corresponding reference for REST and GraphQL APIs — broken object-level authorisation, broken function-level authorisation, mass assignment, server-side request forgery, and the related API failure modes.
- MITRE ATT&CK
- The adversary-behaviour taxonomy we use for red team engagements — initial access, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command-and-control, exfiltration, impact. Anchors the engagement to real adversary tactics rather than abstract risk language.
- CIS Benchmarks
- The configuration baseline we reference for cloud and host security controls — AWS, GCP, Azure, Kubernetes, Linux, Windows — when assessing whether the secure-defaults of the environment are actually in place.
- NIST SP 800-115
- Technical Guide to Information Security Testing and Assessment — the reference for how testing is planned, executed, and analysed, and the cross-check against PTES for scope rigour.
- CVSS v3.1 with business-impact overlay
- Severity is scored with CVSS and then overlaid with a business-impact rationale specific to your environment — the same finding can be a high in a payment-flow context and a medium on a marketing site. See the scoring rubric section below.
- ISO 27001 (and related framework references)
- When GRC advisory is in scope, controls map to ISO 27001 Annex A and to the framework relevant to your buyer audience (SOC 2 Trust Services Criteria, NIS 2 Article 21, DORA, GDPR). We do not run the certification audit — staying independent of the audit is the point.
The HackingByte Engagement Brief
Every engagement ends in three connected artifacts.
-
Technical Report
reproducible findings + evidence
-
Executive Risk Brief
business impact for leadership and board
-
Action Plan
prioritised, owner-assigned, capacity-scoped
The reporting model in depth.
Three artifacts so exploit, control gap, and business impact tell the same story.
-
Technical Report — for your engineers.
The reproducible body of work. Every finding carries: a clear title and category; the affected component, endpoint, or asset; the steps to reproduce, complete enough that an internal engineer can run them in a test environment; the captured evidence (request/response pair, transcript, traffic capture, or screenshot); the CVSS score with the vector string; the business-impact rationale that turned the technical score into a final severity; and the recommended remediation, written for the engineer who will implement it. Findings are grouped by affected component so a single owner can see everything that affects their surface area.
-
Executive Risk Brief — for leadership and the board.
The board-grade narrative. No CVSS tables — the leadership audience does not score vulnerabilities, they make decisions about risk management. The brief answers four questions for them: what did the engagement find, what does it mean for the business if nothing changes, what is the priority order for the next quarter, and what evidence sits behind those conclusions. The same document doubles as the response material when a customer security team or regulator asks how cyber risk is being managed.
-
Action Plan — for the people who will fix it.
Prioritised, owner-assigned, and scoped to the team’s actual capacity. The Action Plan is the bridge between the Technical Report’s findings and your engineering roadmap. Each remediation item carries a clear owner, an effort estimate, dependencies on other items, and a verification criterion so the retest can confirm closure. Keeping security controls up to date depends on this plan being something the team can actually deliver — not a 50-item dump that goes nowhere.
Quality standards.
-
Senior-only delivery.
-
Every report peer-reviewed before it leaves the firm.
-
Severity scored with a business-impact overlay.
-
A 4-hour critical-finding escalation.
Evidence collection and threat response.
Every finding ships with the evidence to reproduce it — and a remediation path your team can act on.
Evidence is collected during execution: HTTP request and response pairs for web and API findings; command transcripts and screenshots for host and cloud findings; traffic captures and proof-of-concept artifacts for chained exploits; and, for red team engagements, an attack-path narrative that ties each step back to the MITRE ATT&CK tactic. Evidence is anonymised where it touches real customer data and is retained under our standard engagement evidence-retention policy.
Each finding pairs evidence with a remediation path. The recommendation is written for the engineer who will implement the fix — concrete config change, code change, control change, or process change — not a generic "apply best practice" note. Where a finding is fundamentally about how malicious software or untrusted input is allowed to reach a sensitive surface, the remediation goes to the layer that should have stopped it, not the layer where it was detected.
For ongoing programmes, the Action Plan flows into the team’s existing engineering and risk-management workflows — Jira, Linear, GitHub Issues, ServiceNow — so vulnerability management becomes part of how the team already ships, not a parallel spreadsheet.
How we score severity.
CVSS for the technical score; a business-impact overlay for the final severity.
Every technical finding is scored with CVSS v3.1 — the standard the rest of the industry uses, so the score is portable across your existing security tooling and your customer-security questionnaires. The CVSS vector is published with the finding so the score can be re-derived, challenged, or adjusted as the environment changes.
The CVSS score is then overlaid with a business-impact rationale specific to your environment. The same finding does not deserve the same final severity in every context: an SSRF on an isolated marketing-site stack is not the same risk as an SSRF on a payment-processing surface; an authentication-bypass on a sandbox environment is not the same risk as one on a customer-facing production surface. The Executive Risk Brief carries the final severity; the Technical Report carries both the CVSS score and the rationale.
Severity outputs are auditable. The peer reviewer must agree the score; the founder signs off the executive surfaces; the Action Plan inherits the final severity for prioritisation. This is what we mean by senior-only delivery: severity decisions are not delegated.
Reproducibility contract.
Every finding can be reproduced by your team in a test environment.
If your engineers cannot reproduce a finding from the report alone, it does not belong in the report. That is the reproducibility contract.
What this means in practice: command transcripts and request/response snapshots are included verbatim; required preconditions (authentication state, test data, configuration flags, environment variables) are listed; tooling that produced the evidence is named; and where a finding only manifested under a specific timing or race condition, the report describes the condition explicitly. The contract holds across the engagement and during the retest window.
If a finding cannot be reproduced — because the environment changed, the access path closed, or the underlying defect was a transient — the finding is downgraded or withdrawn. We would rather publish fewer findings than carry an unreproducible one into your remediation plan.
What we don’t do.
-
We don’t take vendor commissions.
-
We don’t perform the certification audit.
-
We don’t hand work to a junior bench.
Senior-led and vendor-independent — so our recommendations carry no agenda.
Frequently asked questions
Who does the work — the founder or a junior team?
- Senior practitioners run every engagement. The person who scopes your work is the person who runs it; the founder personally reviews the executive surfaces of every report and signs off the final deliverables. We do not hand work to a junior bench — that is the difference between this engagement model and a tool-led pen-test factory.
How does HackingByte handle false positives and tool output?
- Every automated finding is verified by hand before it appears in any report. Tools accelerate coverage; senior judgment decides what counts as a finding. The reproducibility contract — every finding can be reproduced by your team — is the final gate: if we cannot reproduce it on demand, it does not ship.
Are findings scored with CVSS, your own scale, or both?
- CVSS v3.1 for the technical score (so the score is portable across your existing security tooling and customer-security questionnaires), then a business-impact overlay that produces the final severity for the Executive Risk Brief and Action Plan. The CVSS vector is published with every finding so the score is auditable and adjustable.
Does HackingByte run the ISO 27001 / SOC 2 / NIS 2 audit?
- No — we get you ready and work alongside your auditor or certification body. Staying independent of the audit is the point: our recommendations carry no agenda, and our advice on what to fix is not constrained by what we would later sign off on.
What happens to the evidence after the engagement?
- Engagement evidence is retained under our standard policy — long enough to support the agreed retest window and any follow-up questions — and then deleted, or destroyed earlier on written request. Evidence that touches real customer data is anonymised before it lands in the report.
What if a finding is critical — how is it escalated?
- A 4-hour critical-finding escalation is committed at scoping. If during execution we surface a critical finding (active exploitation in progress, complete authentication bypass, sensitive data exposure that needs immediate containment) we contact the escalation point named at kickoff within four working hours, before the report is written.
If this is how you’d want your own work done, let’s scope an engagement.