STUDENT GUIDE

Work safely on a security project

Security projects can be valuable learning opportunities when the permission, scope, handling rules, and escalation route are clear. If any of those are missing, pause and ask.

For students · Practical guidance · Updated 21 September 2026

Agree the boundary before the tool

A project brief should make it possible to tell the difference between an authorised test and an unsafe action. Confirm the owner, target, time window, allowed methods, and what is explicitly out of scope.

\n

Do not infer permission from curiosity, a hostname, or a credential that happens to work. Written scope protects you, the organisation, and the people whose data may be involved.

\n
  • Record the authorisation and the person who can change it.
  • Use test data and least-privilege access where possible.
  • Stop and escalate when the observed situation differs from the brief.

Handle findings with care

Keep notes limited to what the project needs and follow the organisation's handling instructions. Report a concern through the agreed route instead of sharing it broadly or turning it into a public example.

\n

The DIVD.Works safety page is a concise baseline. The project owner and school may add stricter requirements.

\n
  • Do not access, use, or share systems and information without permission.
  • Report concerns, incidents, or unsafe behaviour promptly.
  • Ask your supervisor when the brief, evidence, or next step is unclear.

NEXT STEP

Keep moving with DIVD.Works.

Read the safety guidance

This guide is general information, not a promise of eligibility, placement, employment, or a specific outcome. Confirm the details for your programme, organisation, and opportunity directly.