Scope and rules of engagement

Scope is the single most consequential thing you write in a security program. Too broad and you receive noise you cannot action; too vague and researchers test systems you did not intend to expose, which is how programs turn into incidents. This document describes how scope and rules of engagement are modelled and enforced.

The scope model

Scope is defined once per program and reused by every model running against it. Each asset carries:

• Type — web application, API, mobile build, network range, source repository, and similar.
• Tier and priority — how critical the asset is, which drives triage order and reward bands.
• Status — in scope, out of scope, or informational (accepted but not rewarded).
• Testing constraints — anything specific to that asset: rate limits, test accounts, windows in which testing is allowed, or prohibited techniques.

Because both engines read the same definition, a target added for a bounty program is immediately covered by an active expert engagement, and vice versa. There is no second scope spreadsheet.

Severity tiers

Severity is modelled per program rather than inherited from a vendor default:

• Each severity band (typically Critical, High, Medium, Low, Informational) has a definition and a reward range.
• Custom severity scoring lets a program weight the platform's default scoring with its own risk model, so payouts follow business impact rather than a generic CVSS reading.
• Change history on severity bands is recorded, so a reward decision can be explained after the fact.

Custom severity scoring is Enterprise-tier. Programs on other tiers use the platform's default severity model.

Rules of engagement

The rules of engagement document what testers may and may not do. On AXUM SEC it is part of the program record:

• Testing boundaries — what is authorised, what is explicitly prohibited, and what requires prior approval.
• Data handling — what testers may do with data encountered during testing, and what must never be exfiltrated or retained.
• Disclosure expectations — when a finding may be discussed publicly, and through which channel.
• Coordination contacts — who to reach in an emergency, and the expected response time.

Acceptance is tracked per participant, so you can show that a researcher or expert agreed to the applicable rules before testing began.

NDA policy and acceptance tracking

For private and expert-led work, an NDA can be attached to the program. Acceptance is recorded per participant with a timestamp; testers without a recorded acceptance do not proceed.

Credential locker and network access

Expert engagements frequently need credentials or access to internal systems:

• Credential locker — access material is distributed under control, scoped to the engagement, and not sent over email or chat.
• VPN tester connectivity — where internal systems must be reached, tester connectivity is provisioned rather than improvised.
• Time-bounded access — access is attached to the engagement window and can be revoked.

Credential locker and VPN access are Professional-tier capabilities.

Scope hygiene

A few habits make a large difference to program quality:

1. Name targets unambiguously. Wildcards and vague hostnames are the main source of out-of-scope submissions.
2. Publish the out-of-scope list. Exclusions are as valuable as inclusions; they save triage time and reduce disputes.
3. Match reward bands to risk. If the reward for a critical asset is the same as for a marketing microsite, you will see the microsite.
4. Review tiers after each cycle. Assets move; scope should move with them.
5. Keep constraints per asset. Rate limits and test accounts belong next to the asset, not in a separate document.

Availability and limits

• Scope definition, severity bands and rules of engagement are available on all tiers.
• Custom severity scoring, advanced vetting controls and custom disclosure timelines are Enterprise-tier.
• Credential locker, VPN access, source code review and retesting are Professional-tier.
• Rules of engagement describe how testing is authorised on the platform. They are not a substitute for your own legal review.

Related docs

• Program models — which model needs which level of control
• Triage pipeline — what happens to out-of-scope and duplicate reports
• Identity and access — how expert access is gated
• Disclosure and safe harbor — the disclosure side of the policy