GRC Practice Exercise: Children’s Image Access

When I was working as an Early Childhood Teacher, I noticed a similar issue and raised it with my manager, who quickly arranged for access to be restricted. Below, I’ve used a fictional childcare scenario to practise a governance, risk and compliance (GRC) review.

The focus was simple. Understand who needs access to children’s images, what could go wrong and which controls would help without getting in the way of legitimate work.

I documented the risk, the evidence I would request, proposed controls and how I would check whether those controls worked.

GRC
Risk Review
Access Control
MFA
Personal Devices
Control Validation

The fictional scenario

Practice scenario | 2026

An example early learning centre uses a cloud app (OWNA) to store and share children’s images with authorised staff and families.

Some educators can sign in from personal devices outside centre hours. The centre manager wants to understand whether this access matches their work needs.

The decision is who needs remote access, when they need it and which devices they should use.

All details are hypothetical. No real children’s images or employer systems were used.

Understanding the risk

1

Define what could go wrong

I started with the information being protected and the people who have a legitimate reason to access it.

Risk statement

If a staff account or personal device is compromised, shared or left signed in, children’s images could be accessed or disclosed by someone without a legitimate need.

Access outside required working hours could create unnecessary exposure. It could also support a legitimate task, so I would need to understand the work before recommending a restriction.

Key lesson

A possible risk does not mean a breach has happened. I did not assign a likelihood rating because the scenario did not provide enough configuration, sign-in or device evidence.

2

Document the evidence to request

Before reaching a finding, I would want to understand how access actually works.

  • Staff roles, current permissions and who approves or removes access when duties change.
  • Sign-in policies, multifactor authentication (MFA), session settings and emergency access arrangements.
  • Personal device rules, device safeguards and whether images can be downloaded or kept on a device.
  • Relevant access logs and incident records, reviewed by authorised staff without exposing children’s images in the exercise.

I documented these as evidence requests. The exercise did not include real policies, logs or account settings to inspect.

Proposed controls

3

Match access to work needs

I proposed starting with an approved access matrix (a record of which roles need which permissions).

  • Role-based access: give staff the access required for their duties and review it when their role changes.
  • MFA: require an additional sign-in check, with suitable session settings and a documented emergency access process.
  • Personal device safeguards: decide whether personal devices are permitted, what protection is required and whether images may be stored locally.
  • Access hours: restrict out-of-hours access where there is no business need, with an approved exception for legitimate duties.
  • Ongoing review: assign responsibility for checking permissions and unusual sign-ins.

Control tradeoff

Restricting access by time alone would not address a lost device, weak authentication or excessive permissions. I treated these as separate questions so the recommendation covered more than access hours.

4

Assign ownership and document exceptions

I proposed that the centre manager own the risk decision and approve the access rules. IT or the app provider would implement the approved settings.

If an educator needs access outside normal hours, the exception should explain the work need, the access allowed and who approved it. I would also include a review date so the exception does not continue without being checked.

Proposed responsibility

The manager decides which access is justified and accepts any remaining risk. The technical team applies the settings, with checks to confirm they match the approved decision.

Checking the proposed changes

5

Plan the validation and follow-up

I wrote a validation plan to explain how the proposed controls could be checked after implementation.

  • Use test accounts to confirm each role can complete its required tasks and cannot access images outside its approved permissions.
  • Confirm permitted access works during approved hours and access denied by the rule is blocked outside those hours.
  • Test an approved exception separately.
  • Check MFA behaviour, relevant sign-in records and the permission review process.
  • Check the personal device rules and safeguards against the approved requirements.
  • Ask staff whether the changes interrupt a legitimate workflow.

I would record any remaining risk, a named owner and a review date. Changes to staff roles or app settings would be a reason to check access again.

Key lesson

A useful check confirms both sides: legitimate work still succeeds and access that should be blocked is actually blocked.

Skills demonstrated

Risk Statements
Evidence Requests
Role-Based Access
Proportionate Controls
Risk Ownership
Approved Exceptions
Validation Planning
Documentation

Outcome

I completed a written practice review covering the risk, evidence to request, proposed controls, responsibilities and validation checks.

This exercise helped me connect my understanding of technology with my teaching experience. The controls need to protect children’s information while allowing educators to do their work.

I also practised explaining a risk clearly, recognising what evidence was missing and giving the decision-maker practical options.

Practice exercise disclosure

This is a self-directed GRC learning exercise using a fictional childcare scenario. It does not describe a real employer’s systems or include children’s data.

The controls and validation checks are proposals. No live system changes or control tests were performed as part of this exercise.

This is not an audit, a legal finding or an official compliance assessment.