Skip to content
Qentak — The Education Operating System

TRUST IS BUILT IN THE DETAILS

Clear questions. Accountable decisions.

Student, staff, and institutional information deserve specific answers. Make access, data handling, and operational responsibility part of the evaluation from the first stage.

Education IT administrators inspecting a network rack together
THE PEOPLEIdentity

Evaluate the boundary between useful context and restricted information.

01 / 03

Review the controls in their deployment context.

01

Architecture & separation

Review institution boundaries, shared services, deployment choices, data location, and how separation will be verified.

02

Protection & recovery

Discuss encryption in transit and at rest, key ownership, backups, restore testing, and recovery responsibilities.

03

Monitoring & accountability

Define significant events, exception review, escalation routes, and the evidence available to investigate a concern.

A PERMISSION HAS A PURPOSE

The same institution. Different access.

Choose a role to explore an illustrative access discussion. This is a design example, not an active authorization configuration.

Teacher

Support learning in the assigned classroom.

An institution should validate normal access, exceptions, delegated administration, and access removal with the responsible teams.

Class rosterAssigned classes
Academic feedbackTeaching responsibility
Fee accountNot part of this role
Confidential case notesRestricted to designated staff

MAKE THE PLAN YOURS

Prepare an evidence-based security review.

Use this session checklist to identify what is ready and what needs an owner.

0 of 5 ready

Confirm evidence before relying on a claim.

This public overview identifies the areas to review. It does not claim independent certification, a completed production security assessment, a specific hosting jurisdiction, or a contractual recovery target. Agree those facts for the actual deployment.

Education systems engineers in maroon and sage testing connections at a workstationSecurity & governanceIdentity → Permitted action

SEE HOW THE WORK CONNECTS

Access follows a responsibility

Evaluate the boundary between useful context and restricted information.

  1. 01

    Identity

    Evaluate the boundary between useful context and restricted information.

  2. 02

    Role and scope

    Evaluate the boundary between useful context and restricted information.

  3. 03

    Permitted action

    Evaluate the boundary between useful context and restricted information.

Illustrative workflow · Shape the details around your institution.

Make the review specific.

Questions worth resolving early.

Does a unified record mean everyone sees every field?

No. Shared identity and context should be separated from permission to read, change, approve, or export a specific record. Review both normal responsibilities and sensitive exceptions.

Where will our institutional data be hosted?

Hosting location and deployment arrangements must be confirmed in the proposed service scope. The public website does not establish a production hosting commitment.

How should backup and recovery be assessed?

Ask who owns backups, what is included, how access is controlled, how restoration is tested, and what recovery objectives and responsibilities are agreed for your deployment.

How can we raise a security question?

Use the enquiry below to describe the requirement or observation. Do not include passwords, exploit payloads, live student data, or confidential evidence; arrange an appropriate channel for technical details.

Security & governance enquiry

Describe the process or issue. Keep student records, passwords, medical information, and payment details out of this public form.