SHH Incident & Safeguarding Logger — User Guide

Purpose

The SHH Incident & Safeguarding Logger is a secure internal tool for recording, tracking, and managing incidents that occur in connection with Sugar Hill Hop events and activities. It provides a structured process for handling everything from minor injuries to serious safeguarding concerns, with a complete audit trail of every action taken.

The plugin is designed to support Sugar Hill Hop’s duty of care, ensure regulatory compliance (GDPR, safeguarding legislation), and provide documentary evidence if incidents are ever referred to external authorities.

Every incident — no matter how minor it seems at the time — should be logged. The record protects both the individuals involved and the organisation.

Roles & Access

Access to the Incident Logger is controlled by four custom roles. Each team member should be assigned the role that matches their responsibilities. WordPress Administrators automatically receive full access.

SHH School Director

Full access to everything: all incident types including safeguarding, all settings, audit log, export, delete, and tiered response controls. This is the only role that can manage plugin settings and permanently delete records.

SHH Safeguarding Lead (DSL)

Full access to safeguarding records and all other incident types. Can apply tiered responses, export data, and view the audit log. Cannot manage plugin settings or permanently delete incidents.

The DSL should be the first point of contact for any safeguarding concern. When a safeguarding incident is created, the DSL receives an automatic email notification marked [URGENT SAFEGUARDING].

SHH Safe Space Team

Can create and manage Safe Space, Conduct, Injury, Theft, Data Breach, and General incidents. Can apply tiered responses and export reports. Cannot access safeguarding records — these are completely hidden from this role.

SHH Instructor

Can create Injury reports and General incidents only. Can view incidents they personally created but cannot see incidents filed by other people. Cannot edit, export, or access the audit log.

This role is appropriate for class instructors who need to log injuries or issues during their sessions but do not need oversight of the broader incident record.

Who can see what — quick reference

Capability	Director	DSL	Safe Space	Instructor
Create incidents	✅	✅	✅	✅
Create safeguarding reports	✅	✅	❌	❌
View all incidents	✅	✅	✅	Own only
View safeguarding records	✅	✅	❌	❌
Edit incidents	✅	✅	✅	❌
Apply tiered responses	✅	✅	✅	❌
Export / reports	✅	✅	✅	❌
View audit log	✅	✅	❌	❌
Delete incidents	✅	❌	❌	❌
Manage settings	✅	❌	❌	❌

Incident Types — When to Use Each

Choosing the correct incident type matters because it determines who is notified, who can access the record, and what labels appear on the form. If you are unsure, start with General Incident — the type can be discussed with the DSL or Director later.

Safeguarding Concern

Use when: There is a concern that a child or vulnerable adult may be at risk of harm, abuse, neglect, or exploitation — whether the concern relates to something observed at a Sugar Hill Hop event or information disclosed by an attendee.

Access: Restricted to the DSL and School Director only. These records are completely invisible to Safe Space Team and Instructor roles.

Automatic actions: The DSL and Director receive an immediate email marked [URGENT SAFEGUARDING]. The record is automatically flagged as confidential.

People labels on form:

Person of Concern — the individual whose behaviour or actions raise the safeguarding concern
Child / Vulnerable Person at Risk — the person who may be at risk of harm

Examples: A child discloses abuse at home; an adult volunteer is observed behaving inappropriately with a minor; a participant shows signs of neglect; someone reports a concern about another attendee’s welfare.

Safe Space / Conduct Incident

Use when: Someone’s behaviour at an event breaches Sugar Hill Hop’s safe space policy or code of conduct. This includes harassment, intimidation, discriminatory behaviour, unwanted physical contact, or any behaviour that makes other attendees feel unsafe or unwelcome.

People labels on form:

Respondent — the individual whose behaviour is being reported
Complainant / Affected Person — the person directly affected

Examples: Unwanted advances on the dance floor; verbal harassment; discriminatory comments; persistent boundary violations after being asked to stop; aggressive or intimidating behaviour.

Injury / Accident

Use when: Someone is physically injured during a Sugar Hill Hop event, regardless of severity. This includes trips, falls, collisions, muscle injuries, and any situation where first aid is administered or should have been.

People labels on form:

Injured Person — the person who was hurt
Other Affected Person — anyone else injured or directly affected

Always record: Whether first aid was given, whether emergency services were called, and any reference numbers provided by paramedics or police.

Examples: A dancer twists their ankle; someone trips over a bag; a collision between dancers; someone feels faint or has a medical episode; a cut from broken glass.

Theft Report

Use when: Personal property or Sugar Hill Hop equipment is stolen or goes missing during an event.

People labels on form:

Suspect (if known) — the person suspected of the theft
Victim — the person whose property was taken

Examples: A phone goes missing from a bag; equipment is stolen from the venue; someone’s wallet is taken from a coat pocket.

Data Breach

Use when: Personal data is accidentally or unlawfully accessed, disclosed, altered, or destroyed. Under GDPR, certain data breaches must be reported to the ICO within 72 hours.

Automatic actions: The Director receives an email marked [DATA BREACH] — 72hr ICO deadline as a reminder of the reporting obligation.

People labels on form:

Person Responsible (if known) — the individual responsible for the breach
Data Subject(s) Affected — the individual(s) whose data was compromised

Examples: An email containing personal details is sent to the wrong person; a spreadsheet with attendee data is left on a shared computer; a USB drive with records is lost; an unauthorised person accesses the membership database.

Conduct Warning

Use when: A formal conduct warning needs to be issued and documented as part of the tiered response system. This is typically used after a pattern of behaviour rather than a single incident — use Safe Space / Conduct Incident for the initial report, then Conduct Warning when a formal step is being applied.

Examples: Issuing a Step 1 formal warning after a series of boundary violations; documenting a Step 2 review meeting; recording a permanent ban decision.

General Incident

Use when: Something happens that should be on record but does not fit neatly into the categories above. When in doubt, use this type — it can always be discussed and reclassified later.

Examples: A fire alarm goes off and the venue is evacuated; a disturbance outside the venue affects attendees; a power cut interrupts a class; a noise complaint is received; something is damaged.

Creating an Incident

Navigate to Incident Logger → New Incident in the WordPress admin menu.

Required fields

Only three fields are mandatory:

Report Type — select the most appropriate incident category
Date & Time — when the incident occurred (defaults to the current time)
Description — a detailed, factual account of what happened

Guidance on writing descriptions

Write as if someone who was not present needs to understand exactly what happened. Include:

What you directly observed or were told
The sequence of events in chronological order
Who was present (even if you do not know their names — describe them)
The location within the venue
Any contributing factors (lighting, floor surface, overcrowding, alcohol)
Direct quotes where possible, using quotation marks

Stick to facts. Avoid opinions, assumptions, or conclusions about why something happened. Write “Person A said they felt uncomfortable” rather than “Person A was clearly upset because Person B was being inappropriate.”

People involved

The form has three people sections. Labels change depending on the incident type:

Reporter — the person filing the report (pre-filled with your name). Tick “Report anonymously” if the reporter wishes to remain unnamed.
Person of Concern / Respondent / Injured Person — the primary subject of the incident (label changes by type).
Affected Person / Complainant / Victim — the person directly affected, if different from the reporter.

You do not need to fill in all people sections. An injury report may only have an Injured Person. A general incident may not have an identifiable subject.

After submitting

A unique reference number is generated automatically (e.g. SHH-SG-202602-001)
Email notifications are sent to the appropriate people based on the incident type and priority
The incident appears on the main list with status Open
An audit trail entry is created recording who filed the report and when

Priority Levels — How to Assess

Priority determines how urgently the incident needs attention. When an incident is marked Urgent or Critical, the Safe Space Team receives an additional email notification alongside the Director.

Low

No immediate risk. The incident is minor and can be reviewed during normal working hours. The situation has already been resolved at the time of reporting.

Example: A small tear in the dance floor surface that has been taped over; a low-value item reported missing a week after an event.

Standard (default)

The normal priority for most incidents. Requires review but there is no ongoing risk. This is the default for all new incidents.

Example: A dancer twists their ankle and is helped off the floor; a complaint about noise levels; a one-off boundary issue that was addressed on the spot.

High

The incident is serious and requires prompt attention within 24–48 hours. There may be ongoing risk, a pattern emerging, or the potential for escalation.

Example: A repeated safe space violation by the same person; an injury that required hospital treatment; a theft of high-value items; a near-miss that could have been more serious.

Urgent

Requires attention within hours. There is active risk to individuals or the organisation. The DSL, Director, and Safe Space Team are all notified.

Example: A serious safeguarding disclosure that needs an immediate response plan; a data breach affecting multiple people with a 72-hour ICO deadline; an assault or threat of violence.

Critical

The most severe incidents requiring an immediate response. Involves imminent danger, serious harm, or situations where external authorities should be contacted without delay.

Example: A child protection emergency; a serious physical assault; a situation requiring police intervention at the venue; a medical emergency with life-threatening injuries.

Status Workflow — From Open to Closed

Every incident moves through a series of statuses that track its progress from initial report to final resolution. Understanding the difference between each status — particularly Resolved vs Closed — ensures your records are accurate and meaningful.

Open

What it means: The incident has been reported but no action has been taken yet. This is the starting status for every new incident.

When to move on: As soon as someone begins reviewing or responding to the incident, change the status to Under Review.

Under Review

What it means: The incident is being actively assessed. Someone is gathering information, speaking to those involved, reviewing evidence, or deciding what action is needed.

When to move on: Once a course of action has been decided and initial steps have been taken, move to Action Taken. If the incident needs to be referred externally, move to Referred to Authorities.

Action Taken

What it means: A response has been carried out. This could be a conversation with those involved, first aid administered, a tiered response applied, venue management informed, or any other concrete action.

When to move on: If the situation requires ongoing observation, move to Monitoring. If the matter is fully dealt with and no further action is needed, move to Resolved. If it has been passed to an external body, move to Referred to Authorities.

Referred to Authorities

What it means: The incident has been reported to or is being handled by an external authority — police, local authority safeguarding team, the ICO (for data breaches), or another relevant body. Sugar Hill Hop may still be involved but the primary responsibility now sits with the external organisation.

When to use the Authority Referral sidebar: Tick “Referred to authorities” and record the authority name and any reference number they provide. This creates an audit trail entry.

When to move on: Once the external process concludes and any required follow-up from Sugar Hill Hop is complete, move to Resolved or Closed as appropriate.

Monitoring

What it means: The immediate situation has been addressed but the incident requires ongoing observation. This is particularly relevant after tiered response Steps 1 or 2, where a person’s behaviour is being monitored over a defined period.

When to move on: If the monitoring period ends without further issues, move to Resolved. If further incidents occur during monitoring, the existing record can be updated and a new incident created for the fresh event.

Resolved ✅

What it means: The matter has been fully addressed, all necessary actions have been completed, and the outcome is satisfactory to all parties (or as satisfactory as the circumstances allow). There is no further action required by Sugar Hill Hop.

Use Resolved when:

An injury was treated and the injured person has recovered or confirmed they are okay
A safe space complaint was investigated, the respondent was spoken to, and the complainant is satisfied with the response
A tiered response was applied and the monitoring period has ended without further issues
A data breach was contained, affected individuals were notified, and the ICO was informed (if required)
A theft was reported to police and the victim does not require further support from Sugar Hill Hop
The root cause has been identified and any preventive measures have been put in place

Always add a Resolution Summary in the sidebar when marking an incident as Resolved. This should describe what was done and the final outcome.

Closed 🔒

What it means: The incident record is complete and no further updates will be made, but the resolution may not be fully satisfactory — or the incident was closed for administrative reasons rather than because it was resolved to everyone’s satisfaction.

Use Closed when:

The incident could not be fully resolved (e.g. the affected person left the community, the subject could not be identified, or evidence was inconclusive)
The complainant chose not to pursue the matter further
A sufficient period has passed with no new information and no further action is possible
The incident was logged in error or is a duplicate (add a note explaining this)
An external authority has concluded their involvement and there is nothing further for Sugar Hill Hop to do, even if the outcome was not what was hoped
A permanent ban (Step 3) has been applied — the tiered response is complete and the decision is final

The key difference: Resolved means “this was dealt with and the outcome is acceptable.” Closed means “this matter is finished, but the outcome may be incomplete, unsatisfactory, or administrative.” Both are final statuses — neither should receive further updates under normal circumstances.

Status decision flowchart

New incident → OPEN

↓

Someone starts looking into it → UNDER REVIEW

↓

Action is taken → ACTION TAKEN

↓

├── Passed to police / safeguarding / ICO → REFERRED TO AUTHORITIES

├── Needs ongoing observation → MONITORING

├── Fully dealt with, good outcome → RESOLVED

└── Cannot be progressed further → CLOSED

The Tiered Response System

The tiered response system is Sugar Hill Hop’s formal disciplinary escalation process. It applies primarily to Safe Space / Conduct incidents and Conduct Warnings, though it can be used on any incident type.

Only users with the shh_apply_tiered_response capability can apply tiered steps (Director, DSL, and Safe Space Team roles).

Step 1 — Private Discussion & Formal Warning

A private conversation with the individual about their behaviour, clearly explaining what is unacceptable and what is expected going forward. This is documented as a formal warning.

When to apply: A first offence that is serious enough to require a formal record, or a pattern of minor issues that have been informally addressed without improvement.

What to record: The date of the conversation, who was present, what was discussed, what the individual was told, and what behaviour change is expected. Use the tiered response notes field and add a timeline note.

Step 2 — Further Review & Possible Suspension

A formal review of the situation, potentially involving a temporary suspension from Sugar Hill Hop events while the matter is investigated or while the individual demonstrates changed behaviour.

When to apply: A second serious incident after a Step 1 warning, or a single incident serious enough to warrant immediate suspension (e.g. physical aggression, severe harassment).

What to record: The review process, who was involved in the decision, the duration of any suspension, conditions for return, and how the decision was communicated to the individual.

Step 3 — Permanent Ban

The individual is permanently excluded from all Sugar Hill Hop events and activities.

When to apply: A third incident after Steps 1 and 2, or a single incident so serious that it warrants immediate permanent exclusion (e.g. assault, safeguarding risk).

What to record: The final decision, who made it, how it was communicated, and any ongoing safety considerations (e.g. if the person may attend other dance events in the area).

Notifications

When any tiered step is applied, the Director and DSL both receive an email notification. This ensures senior leadership is always aware of disciplinary actions.

Working With Incidents

The incident list

The main Incident Logger page shows all incidents you have access to. Use the filters at the top to narrow by type, status, priority, or date range. The search box searches across reference numbers, names, and descriptions.

The statistics bar at the top shows:

Open — incidents not yet resolved or closed
Urgent/Critical — open incidents with high-priority ratings
Follow-ups Due — incidents with a follow-up date that has passed
This Month — total incidents recorded in the current month

Viewing and editing an incident

Click any reference number to open the full incident detail. The left column shows the incident information and timeline. The right sidebar contains the controls for updating status, priority, tiered response, follow-up, authority referral, and resolution.

Remember to click “Save Changes” after making updates to the sidebar fields. Timeline notes are saved independently via the “Add Note” button.

The timeline

Every incident has a timeline that builds a chronological record of everything that happened after the initial report. Use timeline notes liberally — they create an invaluable record if the incident is ever reviewed or referred externally.

Note types available:

General Note — default, for any update or observation
Action Taken — record a specific action that was carried out
Phone Call — document a phone conversation about the incident
Meeting — record a meeting held about the incident
Email Sent — note that an email was sent (and to whom)
Follow-up — record a follow-up check

Evidence & supporting notes

Use the rich text editor to describe any evidence related to the incident. This is not for uploading files directly — instead, describe what evidence exists and where it is stored (e.g. “Photo of the damage saved in the SHH shared drive under /Incidents/2026-02/”, “CCTV footage requested from venue management on 10 Feb”).

Follow-up dates

If an incident requires follow-up action, tick “Follow-up required”, set a date, and describe what needs to happen. When the follow-up date arrives, the incident creator and the Director receive an email reminder. The dashboard also shows a count of overdue follow-ups.

Individual timelines

Click “View full timeline for this person” on any subject or affected person’s name to see every incident involving that individual across the entire system. This is particularly useful for identifying patterns of behaviour before applying tiered responses.

Exporting & Reporting

The plugin offers several export options, each suited to a different purpose. All exports are recorded in the audit trail.

Full exports (CSV and Print/PDF)

Available from the incident view page via the Export CSV and Print / PDF buttons. These contain every field including all personal information, descriptions, notes, evidence, and authority referrals. These should only be shared with authorised personnel, external authorities (police, safeguarding teams, ICO), or legal advisors.

The Print / PDF export opens a clean, professionally formatted page in a new tab. Use your browser’s Print function (Ctrl+P / Cmd+P) to save as PDF.

Bulk CSV export is available from the list page via the Export CSV button. This respects whatever filters are currently applied — so you can export, for example, all safeguarding incidents from the last 6 months.

Venue reports (redacted)

Available from the incident view page via the Venue CSV and Venue PDF buttons, and from the list page via the Venue Report button.

Venue reports are specifically designed for sharing with venue management. All personally identifiable information is stripped:

Included: Reference number, incident type, status, priority, dates, venue, location detail, whether first aid was given, whether emergency services were called, tiered response level, follow-up status, whether authorities were involved, resolved date.

Removed: All names, emails, phone numbers, roles, descriptions, notes, injuries text, first aid details, follow-up notes, resolution summary, evidence notes, police references, authority details, and the full timeline.

The printable venue report includes a yellow privacy notice explaining that the report has been redacted, and directs the venue to contact the Sugar Hill Hop Safeguarding Lead for further details.

The Audit Trail

Every action in the Incident Logger is recorded in an immutable audit trail. This includes:

Action	What is logged
Incident Created	Who created it, the type, and reference number
Incident Viewed	Every time someone opens an incident record
Incident Updated	Any change to any field
Status Changed	Old and new status values
Note Added	Type of note added
Tiered Response Applied	Previous and new step levels
Referred to Authority	Which authority and reference
Export Generated	Type of export (CSV, Print, Venue CSV, Venue PDF)
Unauthorised Access Attempt	When someone tries to access a record they do not have permission for (includes IP address)
Incident Deleted	What was deleted and by whom

The audit log is accessible via Incident Logger → Audit Log (Director and DSL roles only). It can be filtered by action type, date range, and searched by keyword.

The audit trail exists to protect everyone — the organisation, the team handling incidents, and the individuals involved. It provides evidence that incidents were handled properly and in a timely manner.

Frequently Asked Questions

Someone reported an incident verbally — do I still need to log it?

Yes. If someone tells you about an incident, you should log it on their behalf. You can either enter their name as the reporter, or if they prefer anonymity, tick “Report anonymously.” Add a note in the description that the incident was reported verbally and logged by you.

I am not sure which incident type to use.

Use General Incident. It is always better to log something under the wrong category than not to log it at all. The type can be discussed with the DSL or Director, and while the type field cannot be changed after creation, a new record of the correct type can be created with a note referencing the original.

Can I edit an incident after it has been submitted?

Yes, if you have the appropriate role (Director, DSL, or Safe Space Team). All edits are recorded in the audit trail. Instructors cannot edit incidents after submission — they should contact someone with a higher access level.

What is the difference between Resolved and Closed?

Resolved = the situation was fully dealt with, and the outcome is acceptable. Closed = the matter is finished, but the outcome may be incomplete or unsatisfactory. See the Status Workflow section for full guidance.

Should I reopen a resolved or Closed incident if something new happens?

Generally, no. Create a new incident and reference the original in the description (e.g. “This is related to SHH-SS-202601-003”). This keeps the timeline clean and ensures each event has its own complete record. The individual timeline feature will show both incidents together.

Who receives email notifications?

All incidents: The School Director
Safeguarding incidents: The Director and DSL (marked URGENT)
Data breaches: The Director (marked with 72-hour ICO deadline reminder)
Urgent/Critical priority: The Director plus the entire Safe Space Team
Tiered responses: The Director and DSL
Follow-up reminders: The Director and the person who created the incident

Can incidents be permanently deleted?

Yes, but only by users with the Director role or WordPress Administrators. Deletion permanently removes the incident record, all associated notes, and all audit entries for that incident. A system-level audit entry is created recording what was deleted and by whom. This should only be used for records created in error or for legitimate data protection reasons — not to remove inconvenient records.

What should I do if I see an “Unauthorised Access Attempt” in the audit log?

This means someone tried to view or export a record they do not have permission to access (most commonly, a non-DSL user trying to view a safeguarding record). Investigate whether this was accidental (e.g. someone clicked a link they did not realise was restricted) or deliberate. If deliberate, this should itself be logged as a General Incident or discussed with the Director.

How long should we keep incident records?

Follow Sugar Hill Hop’s data retention policy. Safeguarding records typically have longer retention requirements than general incidents. The plugin uses soft deletion by default (records are hidden but not destroyed), and permanent deletion is available when the retention period expires. Consult with the DSL and Director before permanently deleting any safeguarding records.