OFF.SECOffensive Security & Audits

    Find Vulnerabilities First

    Threat-led penetration testing (TLPT) and adversary emulation. We bypass controls and chain attack paths so you can see where the business actually takes damage.

    Our Offensive Principles

    A scanner report is not assurance. We define the objective, chain the exploit by hand, and hand you a PoC your own engineer can re-run.

    01

    Objective-Led Testing

    Every engagement is scoped to a business objective. That can be a breach of core banking systems or full control of domain administration.

    02

    Exploitability Over CVSS

    We report on exploitability. Low-severity findings get chained by hand until they produce a compromise with real impact.

    03

    Regulatory Assurance

    Our penetration testing and red teaming methodologies are strictly aligned to satisfy compliance mandates under DORA, NIS2, ISO 27001, and TIBER-EU.

    04

    Engineering-Grade Reports

    Two outputs from every engagement: an executive narrative for the board, and reproducible PoCs with prioritized remediation code for your developers.

    Our Offensive Security Services

    Security testing and audits scoped to what a regulator or an attacker will actually look at

    01

    Penetration Testing

    • External and internal network penetration testing
    • Web application security testing
    • Mobile application security assessment
    • Wireless network security testing
    • Social engineering assessments
    02

    Vulnerability Management

    • Automated vulnerability scanning
    • Risk-based vulnerability prioritization
    • Patch management strategy development
    • Continuous vulnerability monitoring
    • Executive reporting and dashboards
    03

    Security Audits & Compliance

    • ISO 27001 compliance auditing
    • GDPR privacy impact assessments
    • Sector-specific compliance (PCI-DSS, DORA, ZoKB)
    • Security policy and procedure reviews
    • Risk assessment and gap analysis
    04

    Red Team Operations

    • Advanced persistent threat simulations
    • Multi-vector attack scenarios
    • Physical security assessments
    • Purple team collaborative exercises
    • Security awareness testing
    Engagement Methodology

    How we test

    Every offensive engagement follows the same scoped sequence. It repeats across web, network, cloud and red-team scopes, and ends with a report the board can read.

    • 01

      Reconnaissance & Scoping

      Passive OSINT, attack-surface mapping, and threat-model alignment with stakeholders. We define rules of engagement, escalation paths, and the precise blast-radius envelope before a single packet leaves our perimeter.

    • 02

      Vulnerability Discovery

      Authenticated and unauthenticated enumeration, targeted fuzzing, and hypothesis-driven hunting. Findings are validated with proof-of-concept and triaged by exploitability.

    • 03

      Exploitation

      Controlled exploitation, privilege escalation and chained attack paths. Every action is logged, reversible and inside the agreed rules of engagement. We do not exfiltrate live data.

    • 04

      Post-Exploitation

      Persistence proofs, lateral-movement reconstruction and blast-radius mapping. We show what a real adversary would do next, and where your detections, controls and segmentation hold.

    • 05

      Reporting & Remediation

      Executive narrative, technical deep-dive with reproducible PoCs, prioritised remediation roadmap, and a free re-test on critical findings. The report is written to be defended in front of an auditor.

    Aligned with PTES · OWASP · MITRE ATT&CK · NIST 800-115 · OSSTMM · ISO 27001 / NIS2
    FAQ

    Frequently asked questions

    Straight answers to what clients ask us most.

    A penetration test looks for vulnerabilities in a defined scope inside an agreed time window. The output is a list of findings with proof of exploitability and a fix for each one. A red team gets an objective rather than a target list, works through techniques catalogued in MITRE ATT&CK, and is measured by how long the defence takes to notice. The two also differ in who is told. The operations team knows about a pentest in advance. For a red team, usually only a handful of people at board level know. Regulation separates them as well. Article 26 of DORA prescribes threat-led penetration testing, a red team formalised under supervisory rules. Techniques are catalogued at attack.mitre.org, the DORA text is on EUR-Lex.

    Threat-Led Penetration Testing is a test driven by intelligence on the adversaries that actually threaten one specific organisation, whose techniques are then simulated against live production systems. Article 26 of DORA (2022/2554) makes it mandatory. Designated financial entities have to run a TLPT at least once every three years, and the test has to cover critical or important functions, including the ones a third-party provider delivers on their behalf. Which entities are designated is decided by the competent authority on systemic importance and ICT risk profile, so the obligation does not follow from company size. Outside the financial sector TLPT is voluntary and pays off where a successful attack would stop operations. The regulation is on EUR-Lex, the TIBER-EU framework is published by the ECB.

    Once a year is the floor most auditors now assume, and the second trigger is significant change. PCI DSS 4.0 states it directly in requirements 11.4.2 and 11.4.3. Internal and external testing has to run at least once every 12 months and after any significant infrastructure or application change. ISO/IEC 27001:2022 sets no interval, but controls A.8.8 and A.8.29 expect structured testing and evidence that findings were remediated. Designated financial entities carry the additional TLPT obligation under Article 26 of DORA once every three years. In practice that is one planned test a year plus shorter targeted tests after major changes. The PCI requirements are at pcisecuritystandards.org, the DORA text on EUR-Lex.

    No. Scope, time window and rules of engagement are agreed up front. Destructive techniques such as DoS or exploits that can crash a service are used only with written consent and usually against staging. The goal is to prove impact, not cause it.

    Yes. The NIS2 Directive (2022/2555) requires security in the acquisition, development and maintenance of systems including vulnerability handling in Article 21(2)(e), and procedures to assess the effectiveness of the measures taken in Article 21(2)(f). A test is the most direct way to make that effectiveness measurable. ISO/IEC 27001:2022 covers the same ground through controls A.8.8 and A.8.29. In the Czech Republic both land through Act No. 264/2025 Coll. and its decrees for the higher and lower obligation regimes. We structure the report so an auditor finds scope, methodology, date and remediation status on one page. The NIS2 text is on EUR-Lex, the Czech legislation on zakonyprolidi.cz.

    Validate Your Security Posture

    Put a senior offensive team against your architecture before a real adversary does. Objective-led scope, reproducible PoCs, executive narrative. Scope your engagement today.