📜 Online Safety Incident Response for Youth Organisations

01 Designing a Reporting Flow Young People Will Actually Use

A reporting system only works if young people understand where to go, trust what will happen next, and feel safe enough to use it. That means designing the flow around how young people actually seek help, rather than giving them one generic "Report" button.

1. Match the reporting route to the problem

Young people don't use the same route for every type of concern. Depending on the situation, they may approach a trusted adult, seek professional support, use the platform's reporting tools, or speak to a peer. Your reporting flow should reflect these different needs rather than forcing every concern through the same channel.

2. Offer more than one channel

At minimum, offer a direct route to a trusted person within the organisation, a platform-level reporting function, and a clearly signposted path to external support. Your Digital Community Lead, introduced in How to Choose Safe Online Community Platform, can provide a human point of contact, while services such as Kids Helpline or Lifeline can support situations that fall outside your organisation's role.

3. Remove the barriers that stop young people reporting at all

A reporting mechanism can exist without being used. Fear of punishment, stigma, or being talked down to can all discourage young people from asking for help. Make the process approachable, explain what will happen after someone reports, and avoid language that makes reporting feel like getting someone "in trouble."
This is why the way you communicate with young people matters as much as the reporting mechanism itself. For more on designing youth participation and communication around their actual needs, see Reaching Young People: How to Communicate in a Changing Digital Environment.

4. State confidentiality and consequences up front, every time

Before anyone reports anything, they should already know what stays confidential, and that reporting isn't automatically punished. Saying this once in a policy document buried on your website doesn't count, it needs to be visible at the point of reporting.

02 Documentation: What You Need to Prove Due Diligence

A safe digital community needs more than good intentions. You need a small set of documents that show how the community is run, how risks are handled and who is responsible.

Here's the minimum set.

1. Community / acceptable use policy: Clear rules for behaviour, written so young people can actually understand them. Avoid legal boilerplate.

2. Digital safeguarding policy: Explain how safeguarding works in the online space, including access controls, moderation and escalation. This should connect to your organisation's wider safeguarding policy.

3. Incident log: Record reports, actions taken, escalation level and outcome. Consistent records help you identify patterns and improve your approach.

4. Data and privacy statement: Explain in plain language what you collect, who can access it, why you need it and how long you keep it.

5. Review record: Document when policies, settings and safety processes are reviewed and what changed. A policy should be maintained, not written once and forgotten.

6. Ownership record: Document who is responsible for day-to-day community management, moderation, safeguarding escalation and organisational oversight. The RACI from Chapter 6 can do this.

The goal isn't to create a folder full of documents.

It's to make sure that if someone asks “Who is responsible, what happens when something goes wrong, and when was this last reviewed?”, your organisation has a clear answer.

Hear the conversations behind this guide

This guide draws on conversations with people working across the youth sector. If you want to hear directly from some of those perspectives, listen to Raising Youth Voices, NARU's podcast exploring youth connection, belonging and safety in a changing digital environment.

Listen to Raising Youth Voices: Beyond the Ban →

04 Incident Response: What to Do When Something Goes Wrong

Something will go wrong eventually, a report might involve bullying, unwanted contact or a breach of community rules. Or it might be a safeguarding concern that needs to leave the community team entirely.

The important thing is that the person handling the report shouldn't have to invent the response while they're dealing with the incident.

1. Offer more than one way to get help.

A single “Report a problem” button is useful, but it shouldn't be the only route to support.

Young people may need help from different people depending on what has happened: a moderator for a community issue, a trusted adult for something personal, a counsellor for a mental health concern, or an external authority where there is an immediate safety or legal issue.

2. State confidentiality and consequences up front, every time.

Say explicitly, before anyone reports: what stays confidential, and that reporting isn't automatically punished.

Don't promise absolute confidentiality if there are circumstances where the organisation has a duty to escalate. The goal is to remove uncertainty, not to make promises you can't keep.

3. Build an escalation pathway

Moderators shouldn't have to decide in the moment whether something is serious enough to escalate. Set the pathway in advance.

For example: Peer support → Moderator → Digital Community Lead → Safeguarding lead / external authority

The exact structure will depend on your organisation, age group and safeguarding responsibilities. The important part is that everyone knows where their responsibility ends.

A moderator might be able to remove a harmful post or pause a conversation. They may not be the right person to handle a disclosure of abuse, a credible threat or another serious safeguarding concern. Those boundaries should be clear before an incident happens.

4. Make reporting easy enough to use

A reporting system can exist and still fail if young people don't trust it.

Think about the practical barriers.

Is the reporting process easy to find? Does it require too much information? Does the young person know who will receive the report? Will they understand what happens afterwards?

Your reporting process should also work alongside the other ways young people already seek help.

5. Follow up after the immediate problem is handled

Resolving an incident doesn't necessarily resolve its impact. If someone reports bullying, unwanted contact or another harmful experience, consider what happens after the immediate action has been taken.

Follow-up doesn't have to mean giving someone confidential details about another person's case. It can simply mean letting the person know that their report was received, explaining what you can share, and making sure they know where to go if they need further support.

6. Keep an incident record

Record incidents consistently, including smaller ones, the purpose isn't to create a huge database of everything that happens. It's to help the organisation see patterns that are difficult to spot one incident at a time.

This gives your organisation something more useful than a policy document. It gives you a record of what is actually happening in the community and that record should feed back into the review process.

05 Examples: What This Looks Like in Practice

The following is a hypothetical, composite scenario, not a real case from NARU's research or any real organisation, built to show how Chapters 1–3 work together in sequence. Any resemblance to a specific organisation or incident is coincidental.

"Yooo Youth Connect" is a fictional regional mentoring program for 13–17-year-olds. Its community runs on a private, invite-only group chat server (Discord-style): a few shared channels for program chat, resources, and projects, plus the ability for members to message each other directly. This is a general-purpose community app made workable through deliberate configuration. Two trained 17-year-old youth moderators help run the server alongside the program's staff and mentors.

1. Before anything happens (Chapter 1 in place)

Yooo has a plain-language acceptable use policy, a digital-specific safeguarding policy naming its four escalation tiers, an incident log template, a short data and privacy statement, and a one-page RACI naming its Program Coordinator as Digital Community Lead. Following Article 2's safety-by-design checklist, direct messages between members are off by default and only switch on when both people opt in. Three reporting routes are visible in the server: message a youth moderator directly, use a staff-monitored "ask a mentor" form, or follow a pinned link to Kids Helpline. Each carries a short note on what stays confidential and that reporting never leads to automatic punishment.

2. The incident

Over about two weeks, Jordan (14) starts leaving mocking comments on Sam's (14) posts in the program channel. At first it reads as teasing, but it becomes repeated and pointed. Jordan and Sam had opted in to DMs earlier as friends, and Jordan then starts sending Sam messages telling him his work is embarrassing and that he should leave the group. Sam stops posting. He doesn't report anything himself.

3. The report (Chapter 2)

Alex, another member, notices Sam has gone quiet and messages one of the youth moderators directly: Sam's been getting nasty messages from Jordan and has stopped coming. Alex chose the person they already trusted rather than a generic report button, exactly the pattern the help-seeking research describes, and could do so safely because the confidentiality note was already visible.

4. The escalation (Chapter 3)

• Youth moderator level. The moderator checks in with Sam privately first, before doing anything else: he's not in trouble, what he shares stays confidential unless someone's safety is at risk, and he decides whether he wants to share the messages. With Sam's permission, they save screenshots. The moderator then removes the mocking comments from the channel, squarely within a youth moderator's written mandate.

• Escalation to the Digital Community Lead. Because the behaviour is repeated and has moved into private messages, the moderator escalates to the Program Coordinator rather than handling it alone, as the ladder specifies for repeated behaviour.

• Digital Community Lead level. The Lead speaks with Sam first. Consistent with the finding that loneliness is the most common underlying issue, Sam says he had felt isolated and now isn't sure he wants to come back; the Lead focuses on that, not only on the incident. The Lead then speaks separately with Jordan. The aim is accountability without humiliation; young people consulted in the eSafety-commissioned research said they want harm to be taken seriously but also want children who make mistakes to be shown compassion. Jordan acknowledges the messages, receives a formal warning, and DM access between the two is switched off. Both young people's parents or guardians are contacted in line with the safeguarding policy.

• Why it didn't reach the external authority tier. There were no threats, no sharing of images, no contact from an adult, and nothing illegal. Any of those would have moved it straight to the top of the ladder.

5. Documentation and follow-up

The incident is logged in the same day, including the date, nature of the report, tiers involved, actions taken, and outcome. The Lead checks in with Sam a week later and again a month later, separately from the formal resolution, because isolation often outlasts the incident itself.

6. The review cycle

In the next scheduled review, the Lead notes that the harassment moved from a public channel into DMs and brings it to the executive director in the quarterly report. The team decides to turn DMs off by default for members under 14, even where both people opt in, and updates the safeguarding policy to match.

Why this matters

None of Yoo's response was improvised. Who Alex told, what the moderator could decide alone, when it escalated, what got logged, and who followed up were all settled in advance by documentation written when nothing was wrong. And because the incident log fed straight back into the review cycle, one incident improved the system for everyone who came after.

06 Action Plan: What to Do Next

1. This week: Check which of the six documentation items in Chapter 2 you actually have in writing, versus which ones exist only as informal practice.

1. This month: If your incident log doesn't exist yet, create it now, before you need it, not after your first incident.

2. Before you need it: Build at least three reporting channels (Chapter 1), and make confidentiality and consequences visible at the point of reporting, not buried in a policy page.

3. This month: Draft your escalation ladder (Chapter 3) with named tiers and named people responsible for each, even if some tiers are currently the same person wearing different hats.

4. Ongoing: Set a fixed review date for your entire incident response and documentation set, six months out from today is a reasonable starting point.

07 FAQ

What policies do funders expect us to have in writing?

At minimum: an acceptable use policy, a digital-specific safeguarding policy, an incident log, a data and privacy statement, a documented review cycle, and a named ownership record. Chapter 1 covers each in detail.

How do you handle a safeguarding incident in an online youth community?

Follow a pre-defined escalation ladder rather than improvising: assess severity, route to the appropriate tier (peer, moderator, Digital Community Lead, or external authority), maintain confidentiality, log it regardless of outcome, and follow up after resolution.

Is a single "report" button enough?

No. Young people match the type of helper to the type of problem, a single generic channel doesn't reflect how they actually seek help. Build at least a direct line to a trusted adult, a platform report function, and a signposted path to external services.

What's the most common mistake organisations make with incident response?

Writing the protocol after the first incident rather than before. Every practitioner NARU spoke with who described a difficult situation also described having to improvise the process while handling it.

What should an incident log actually record?

Date, a brief description, which escalation tier it was handled at, and the resolution, recorded for every report regardless of how minor it seemed, since this log is the primary evidence a funder or regulator will ask for.

09 Methodology & Sources

This guide draws on three layers of evidence: NARU's original interviews, published third-party research, and NARU's own synthesis of the two.

NARU's original research

The guide is primarily informed by NARU Research: Interviewee Perspectives on Australia's Under-16 Social Media Ban, based on 20 semi-structured interviews with program managers, educators and thought leaders working in youth-facing services.

The interviews were conducted between July and September 2026. Practitioner quotes and named examples in this guide come from those conversations. The full research digest, including interviewee profiles and cited quotations, is available separately.

Published research

We also drew on research and guidance from:

• eSafety Commissioner. (2026). Attitudes of children and parents to social media age restrictions ahead of implementation. Australian Government.

• eSafety Commissioner. (2025). Social media age restrictions. Australian Government.

• Young and Resilient Research Centre, Western Sydney University, in partnership with the eSafety Commissioner. Consultations with young people to inform the eSafety Commissioner's Engagement Strategy for Young People.

• Prevention United. (2026). Navigating artificial intelligence for youth mental health

• Maidment, K., Tonna, Z., Houlihan, M., & Carbone, S. (2024). The impact of screentime and social media on the mental health of young Australians. Melbourne: Prevention United.

• Verghese, A. (2025). Instagram Teen Accounts fail to protect children, safety tools testing reveals. Fairplay.

• United Nations Human Rights Office. (2026). Getting Children's Safety Online Right.

• Yoon, J., Zhang, A. X., & Seering, J. (2025). "It's Great Because It's Ran By Us": Empowering Teen Volunteer Discord Moderators to Design Healthy and Engaging Youth-Led Online Communities. Proceedings of the ACM on Human-Computer Interaction, 9(2), 1–30.

Limitations

NARU's interview sample of 20 practitioners was not designed to be statistically representative. It reflects people working in youth-facing roles rather than a random cross-section of the sector or young people themselves.

Where evidence is still developing, particularly around the effects of Australia's social media age restrictions, we have identified that uncertainty rather than presenting assumptions as findings.

Update Triggers

We will revisit this article when: eSafety releases findings from its Social Media Minimum Age evaluation (expected progressively across 2027–2028); the list of platforms covered by the Act changes; or new peer-reviewed research on youth digital communities is published.