Our Methodology: How We Work

Nokta Guard conducts penetration tests using a defined methodology based on public frameworks such as OWASP WSTG, OWASP MASTG, the OWASP API Security Top 10, PTES, NIST SP 800-115 and OSSTMM. Our experts manually validate the output of automated tools and report every finding with evidence. Findings are scored with CVSS, and attack scenarios are mapped to MITRE ATT&CK where relevant.

No single standard covers every type of test, so we follow the guide that fits the target system.

• OWASP WSTG (Web Security Testing Guide): The basis of our web application test checklist; the current stable release is v4.2.
• OWASP MASTG and MASVS: In mobile application testing, we verify the security requirements in MASVS using the test methods in MASTG.
• OWASP API Security Top 10 (2023): We test authorisation, authentication and resource consumption risks in REST and GraphQL APIs.
• PTES (Penetration Testing Execution Standard): We use it to define the stages of the process, from pre-engagement to reporting.
• NIST SP 800-115: The technical guide we reference for structuring the planning, discovery, attack and reporting phases.
• OSSTMM: An open methodology we draw on to assess operational security measurably in network and infrastructure tests.
• MITRE ATT&CK: A knowledge base of real-world adversary tactics and techniques; we map findings to it, particularly in internal network, red team and purple team work.

1. Pre-engagement and scoping: We agree in writing on target systems, test type, testing window and rules of engagement.
2. Reconnaissance and discovery: We map the target's attack surface, services and technologies using open sources and active scanning.
3. Vulnerability identification: We combine automated scan results with manual analysis and eliminate false positives.
4. Controlled exploitation: We exploit vulnerabilities in a way that does not harm systems, to demonstrate their real impact.
5. Post-exploitation: Where in scope, we assess privilege escalation and lateral movement to show how far an attacker could go.
6. Reporting: We document each finding with impact, CVSS score, evidence, reproduction steps and remediation guidance.

Scanners find known vulnerabilities quickly but often miss business logic flaws and authorisation issues. We therefore treat automated output as a starting point, and our experts test critical flows manually. Only validated findings make it into the report.

In a black-box test, our team works without prior knowledge of the target, like an external attacker. In a grey-box test, limited information such as a user account is provided; for most organisations this is the most efficient approach. In a white-box test, architecture documents or source code are shared, allowing the deepest review.

• We do not start testing without written authorisation and agreed rules of engagement.
• Tests that could cause service disruption are run only with your explicit approval and within the agreed window.
• We limit access to personal and confidential data to what is needed to prove a vulnerability, and we do not copy data.
• When we find a critical vulnerability, we notify your designated contact immediately rather than waiting for the report.

At Nokta Guard, a penetration testing project moves through request, scoping form, proposal and contract, authorisation and rules of engagement, testing, reporting, presentation and retest. Each step has a defined output, and the next step does not start until that output is approved. That way you know from the outset what happens when and what will be delivered.

1. Request: You contact us via the form, email or phone, and we discuss your needs and goals in a short initial call.
2. Scoping form: Together we complete a form covering the applications, IP ranges, user roles and environments to be tested. It is the basis for estimating effort accurately.
3. Proposal and contract: We prepare a proposal covering duration, testing approach and deliverables. Once approved, a service agreement and a non-disclosure agreement are signed.
4. Authorisation and rules of engagement: Test dates and times, source IP addresses, out-of-scope systems, emergency contacts and prohibited test types are agreed in writing. Testing does not begin without this document.
5. Testing: Our team carries out the test in line with our methodology. If we find a critical vulnerability, we notify your contact immediately rather than waiting for the report.
6. Reporting: Findings are documented with an executive summary, risk matrix and technical detail, and delivered encrypted.
7. Presentation: We review the results with your management and technical teams and agree remediation priorities together.
8. Retest: Once you complete your fixes, we retest the relevant findings and document their status in a separate retest report.

Duration depends on scope. We confirm the timeline in the proposal after scoping.

• A completed scoping form and access details for the test environment
• A technical contact who is reachable throughout testing
• Test accounts for the relevant roles in grey-box tests
• Where required, notification to your hosting or cloud provider

Nokta Guard penetration test reports consist of an executive summary for decision-makers, a risk matrix that shows exposure at a glance, and, for technical teams, evidence, reproduction steps and remediation guidance for every finding. Reports are delivered encrypted and are completed with a separate retest report once fixes are in place.

• Executive summary: The objective, scope, overall security posture and priority actions, explained in one or two pages without jargon.
• Scope and method: The systems tested, testing dates, approach (black/grey/white box) and frameworks referenced.
• Risk matrix: The distribution of findings across Critical, High, Medium, Low and Informational levels.
• Technical findings: Each finding detailed using a standard template.
• Appendices: Tool output, lists of tested addresses and additional evidence where needed.

• Title and risk level
• Impact: The possible consequence for the business and its data if the vulnerability is exploited
• CVSS score and vector
• Affected system, address or parameter
• Evidence: Screenshots, request-response samples or command output
• Reproduction steps: A step-by-step explanation so your team can verify the finding in its own environment
• Remediation: Actionable fixes and, where needed, interim mitigations
• References: Related CVE, CWE or OWASP resources

We measure technical severity with CVSS, agreeing on the version (3.1 or 4.0) during scoping. When assigning the final risk level, we also consider exploitability and how important the affected data is to your organisation.

Once you complete your fixes, we retest the findings and report each one as Closed, Partially Closed or Open, with evidence. The report is delivered as a separate document so you can show auditors or management that findings have been resolved.

Reports are delivered encrypted through a sharing environment where access is logged, and the password is sent through a separate channel. Reports and test data are either not retained at all or stored encrypted for 3 or 6 months, as you prefer, and then securely destroyed.

• Who will perform the test?: Ask about the team's experience and certifications, and whether the work will be subcontracted.
• Which methodology will be used?: Ask for a recognised framework such as OWASP, PTES or NIST SP 800-115, with manual verification.
• Will testing harm our systems?: Rules of engagement, test hours and emergency contacts should be in writing; risky steps should never run without your approval.
• Is retesting included?: The proposal should state clearly when and to what scope fixes will be retested.

A defined methodology ensures that two different tests are performed with the same rigour and that results are comparable. Knowing why each step is taken also gives confidence when you present the report to an auditor or management.

Methodology is also a safety boundary. Because the systems, methods and permissions involved are agreed in writing beforehand, both your systems and any data that may serve as evidence stay under control.

• Penetration Testing Methodology: An approach based on OWASP, PTES, NIST SP 800-115 and OSSTMM.
• Project Process: A step-by-step workflow from scoping to retesting.
• Reporting Approach: Executive summary, technical findings and actionable remediation guidance.
• Digital Forensics Methodology: Chain of custody, hash verification and alignment with international guidelines.

In forensic examinations, Nokta Guard focuses on preserving the integrity of digital evidence from the moment it is received until the report is delivered. Evidence is logged on a handover record, imaged with a write-blocker where technically possible, verified with hash values such as SHA-256, and analysed on a copy rather than the original. Our approach references the principles of the ISO/IEC 27037 guideline.

ISO/IEC 27037 is an international guideline for the identification, collection, acquisition and preservation of digital evidence. We base our examinations on its principles of auditability, repeatability and justifiability. For live systems, we draw on RFC 3227 for the order in which volatile data is collected.

1. Initial assessment: We listen to the incident, the purpose of the examination and the condition of the devices, and assess which examinations are technically feasible.
2. Evidence handover record: Make, model, serial number, physical condition, the people handing over and receiving the device, and the date and time are recorded.
3. Chain of custody log: Who held the evidence, when and for what purpose is recorded throughout the examination.
4. Forensic imaging: A bit-level copy of storage media is taken using a hardware or software write-blocker where technically possible. For mobile devices, the acquisition method depends on the model, operating system version and lock status.
5. Hash verification: Hash values (e.g. SHA-256) of the original source and the image are calculated and compared, then recorded on the handover form and in the report.
6. Analysis on a copy: The examination is carried out on a working copy of the verified image; the original evidence is preserved untouched.
7. Reporting: Methods, tools, hash values and findings are presented in an objective report that non-technical readers can follow.
8. Return and retention: The original evidence is returned with a record; images and working files are either not retained at all or kept for 3 or 6 months, as the client prefers, and then securely destroyed.

On a running computer, volatile data such as memory may be lost when the device is shut down, so collecting it first may be considered. For locked, encrypted or physically damaged devices, advanced methods such as chip-off may be considered; because these can involve irreversible steps depending on the device's condition, they are applied only with your written approval. What data can be obtained depends on the device's condition and the technology involved.

Our reports set out technical findings impartially. Whether a report is admitted as evidence in proceedings, and how much weight it carries, is at the discretion of the relevant authority. Nokta Guard is not a court-appointed expert witness; we provide expert opinion and technical consultancy.