Concepts & terminology

A quick map of the vocabulary used throughout this site, before diving into any one workflow.

Core objects

Engagement : The top-level unit of work: one penetration test, vulnerability assessment, or remediation retest for one client. Everything else (findings, checklist runs, scanner imports, reports) belongs to exactly one engagement. See Engagements.

Finding : A single vulnerability or observation recorded against an engagement, with a severity, CVSS score, classification tags, and a set of admin-configured rich-text sections (description, technical details, business impact, etc.). See Findings.

Vulnerability catalogue : A reusable, org-wide library of pre-written findings that can be imported into any engagement instead of writing one from scratch. See Vulnerability catalogue.

Checklist / Checklist template : A checklist template (e.g. OWASP WSTG) defines a reusable list of test objectives. A checklist run is one instantiation of a template against a specific engagement, and an engagement can have several runs (say WSTG against the web app alongside API Top 10 against its API). See Checklists.

Report Profile : A named report configuration: its Document template (free-form, tag-driven), optional uploaded .docx template, branding, colors, fonts, and text blocks. An engagement’s report is generated by rendering its data through a chosen profile. See Reports & exports.

Client company / Client account : A Client groups engagements under one customer organization. A client account is an external login tied to a client company, restricted to the Client Portal.

Role : A named, dynamically-configurable set of permissions (Role Management) assigned to every staff user. Four built-in roles ship by default, Superadmin, Team Lead, Senior, and Consultant, and custom roles can be created with any combination of permissions. See Roles & permissions.

Workflow states you’ll see everywhere

Engagement status moves through In Progress → In Review → QA → Approved → Delivered, with Awaiting Remediation Test / Remediation Test as a side branch once a retest is needed, and Closed as the terminal state. Archiving is a separate, orthogonal flag: an engagement in any status can be archived (soft-deleted) and later unarchived, and only a Superadmin can permanently delete an already-archived engagement.

Finding workflow status is independent of the engagement’s own status: Draft → Reviewed → QA Approved, with Changes Requested (Review) / Changes Requested (QA) as the reject path back to Draft at either stage. Only a QA-approved finding is ever visible in the Client Portal.

Finding status (Open / Closed) is a separate axis again, tracking whether the underlying vulnerability itself is still present. That’s tracked via retest status (Not Retested, Fixed, Not Fixed, Partially Fixed, Risk Accepted) once a remediation retest has been logged.

See the Data model & status reference for the complete, authoritative list of every status/severity enum in the app.