School data ownership, export and deletion questions

Which school data is actually in scope?

Start with how the school plans to use the platform, not with the vendor's full catalogue. List each category of data the school expects to place in the system, then record its purpose, its source, the school owner accountable for it and the people who need it.

Include derived and copied data too. A dashboard total, a notification, a synchronised field or a backup starts from an original record but follows its own path. Trace one sample record from collection through correction, sharing, export, retention and disposal; any step nobody can explain becomes a written question for the vendor.

What should “data ownership” mean in the contract?

Data ownership should mean the school can obtain, use and delete its records on request, and the terms say how. A line such as “the school owns its data” answers none of the practical questions below. For each, ask where the answer appears (contract, privacy notice, product documentation or proposal) and get conflicts between documents resolved in writing.

Access

Who at the vendor may open school data, and for which purposes?

Instructions

Whose instructions govern processing, and how are they given?

Secondary use

Is any data used for another purpose, such as product analytics?

Subcontractors

Which other services handle the data, and how is the school told of changes?

After the agreement

Which rights continue once the contract ends, and for how long?

What must a test export prove?

Ask an authorised administrator to export a defined sample. Write down beforehand what it should contain, then compare the result with the source records and open the files with tools the school already has. Anything missing or transformed goes on the record.

• Record counts match the source
• Identifiers survive, so records can be matched again
• Field names are readable and complete
• Timestamps and status history are kept
• Attachments arrive, linked to their records
• Relationships between files, such as student to class, still hold

Also note the formats offered, scope limits, preparation time, delivery method, password handling and cost. Google Workspace Admin Help documents an administrator process for exporting an organisation's data; it shows the kind of documentation to ask for, not what another platform exports.

How should retention, deletion, archives and backups be separated?

First ask which event starts each retention period, category by category, rather than accepting one period for the whole platform:

Ask who can approve a deletion, how mistakes are prevented, whether it can be reversed and how exceptions are reported.

Who can access school data, and how is that access reviewed?

Map access for school users, vendor personnel and any other party named in the arrangement. For each group, ask which data categories it reaches, for what purpose, who approves it, how long it lasts and what record of access remains. Review the exceptional paths as well as ordinary classroom screens. Ask to see the actual controls and the evidence the school will receive at each periodic review. The role-by-role detail sits in the guide to evaluating teacher, student, parent and administrator access.

Support access

Who approves a vendor engineer opening school records, and how the school sees it happened.

Emergency access

Who may grant it, for how long, and who reviews it afterwards.

Bulk export

Which roles can export everything, and whether a second person must approve.

How should Malaysian personal-data material be used?

Malaysia's Personal Data Protection Department sets out seven personal-data-protection principles under section 5(1) of Act 709 and lists six data-subject rights in its public FAQ; the Personal Data Protection Act 2010 places the principles in sections 6 to 12. These points give a school reason to ask precise questions about purpose, disclosure, security, retention, access and correction. They do not decide what a school or vendor must do in a particular arrangement.

What the department publishes on controller duties is set out question by question in the first-meeting privacy guide.

Keep unanswered legal or contractual questions on a separate advice list, and give the adviser:

• The data inventory from the first question above
• The data-flow map and the vendor's written answers
• The proposed contract wording and user groups

What should the school test before signing and during service?

Exit problems are cheapest to find before commitment, and drift is easiest to fix while the contract is running. Split the checks in two, and keep each result with the contract record, naming who decides whether an exception is still acceptable. The school software onboarding checklist covers the steps in between.

Before signing

Run the sample export; get written answers on ownership, access, retention, deletion, backups and exit, each tied to a named contract clause. For anything the vendor cannot show yet, note the reason, owner, due date and effect on the decision.

During service

Repeat a smaller export and an access review at an agreed interval and after major changes, so an incomplete handover is found long before exit.