Concepts & terminology

RedScribe has a handful of core objects that everything else is built from. This page is a quick map of them, so the rest of the site makes sense as you go.

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 issue or observation recorded against an engagement. Each one has a severity, a CVSS score, classification tags, and a set of rich-text sections your admin configures, things like description, technical details, and business impact. See Findings.

Finding catalogue : A reusable, org-wide library of pre-written findings. Import one into any engagement instead of writing it from scratch. See Finding catalogue.

Checklist / Checklist template : A checklist template (say, the OWASP WSTG) defines a reusable list of test objectives. A checklist run is one instance of a template applied to a specific engagement, and an engagement can have several runs at once, for example 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 and tag-driven, or an uploaded .docx template), branding, colors, fonts, and text blocks. An engagement’s report is generated by rendering its data through whichever profile you choose. See Reports & exports.

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

Role : A named, configurable set of permissions assigned to every staff user. Four roles ship by default, Superadmin, Team Lead, Senior, and Consultant, and you can create custom roles with any combination of permissions. See Roles & permissions.

Workflow states you’ll see everywhere

Three different status tracks show up across the app, and they’re independent of each other. Here’s what each one means.

Engagement status moves through In Progress → In Review → QA → Approved → Delivered. If a retest is needed, it branches through Awaiting Remediation Test and Remediation Test before reaching Closed, the terminal state. Archiving is a separate flag: an engagement in any status can be archived (soft-deleted) and later unarchived, and only a Superadmin can permanently delete one that’s already archived.

Finding workflow status tracks a finding through review, separately from the engagement’s own status: Draft → Reviewed → QA Approved, with Changes Requested (Review) and 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 third, separate axis: it tracks whether the underlying issue is still present. That’s set through 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 and severity enum in the app.