Privacy & Data Processing Policy

---

Version 2.0 | Effective: 06 October 2026

How to use this document

This document has two functions. Part A is MasterSoft's privacy and data-handling policy. Part B contains institutional data processing terms intended to satisfy the core requirements of Article 28 GDPR when they are incorporated into a Service Agreement, Purchase Order, Order Form or other binding contract. Where a separate signed DPA or the EU Standard Contractual Clauses apply, those documents prevail to the extent of any conflict.

Part A: Privacy & Data Handling Policy

1. Purpose, scope and application

This Policy explains how MasterSoft ERP Solutions Pvt. Ltd. ("MasterSoft", "we", "us" or "our") handles personal data in connection with its education ERP and SaaS platforms, mobile applications, APIs, integrations, implementation, support, hosting, backup, security and related services (collectively, the "Services").

It is designed to support compliance with Regulation (EU) 2016/679 (General Data Protection Regulation or "GDPR") and other applicable privacy and data-protection requirements. It applies to personal data processed by MasterSoft both (a) for MasterSoft's own legitimate business purposes and (b) on behalf of educational institutions and other customers using the Services.

This Policy does not create a lawful basis for an Institution to collect personal data. Each Institution must independently determine and document its lawful basis, transparency obligations, retention requirements and other Controller responsibilities.

2. Roles under GDPR

2.1 Institutional ERP data

Where an educational institution determines why and how personal data is used within the ERP, the Institution is ordinarily the Data Controller and MasterSoft is the Data Processor. MasterSoft performs operations such as hosting, storage, organisation, retrieval, automated calculation, transmission, backup, recovery, support and deletion on behalf of the Institution. These operations are "processing" under GDPR even where no MasterSoft employee views the underlying data.

MasterSoft does not determine the Institution's academic, examination, admissions, HR, fee, statutory or student-administration purposes. Human access by MasterSoft personnel is not ordinarily required for routine use and is restricted to authorised personnel where reasonably necessary for implementation, support, incident response, security, recovery, legal compliance or other contracted services.

2.2 MasterSoft business and website data

MasterSoft acts as Controller for limited personal data it collects for its own business operations, such as website enquiries, customer/prospect contacts, contract administration, billing contacts, recruitment, event registrations, vendor management and security of its own systems. These activities are governed by Section 5.

2.3 No role expansion by access

MasterSoft does not become Controller of Institutional Data merely because the Services technically store or process that data, or because authorised support personnel access limited data when necessary to perform contracted services. Roles are determined by the actual purposes and essential means of processing and by applicable law.

3. Privacy principles

MasterSoft applies the following principles to personal data within the scope of this Policy:

• Lawfulness, fairness and transparency: processing must have a valid legal basis and be explained appropriately to data subjects.

• Purpose limitation: data is processed only for specified, legitimate purposes and not reused incompatibly.

• Data minimisation: only data reasonably necessary for the relevant educational, administrative, support, security or business purpose should be processed.

• Accuracy: Institutions are responsible for source-data accuracy; MasterSoft provides tools and assistance to correct data where instructed.

• Storage limitation: personal data is retained only for the period required by the Controller, contract, legal obligations and documented backup lifecycle.

• Integrity and confidentiality: proportionate technical and organisational measures protect confidentiality, integrity, availability and resilience.

• Accountability: roles, instructions, security, subprocessors, incidents, retention and rights-handling are documented and reviewable.

4. Categories and sources of data

4.1 Institutional Data

Depending on the modules selected by an Institution, Institutional Data may include:

• identity and profile data (such as name, institutional identifier, photograph, date of birth, gender or other profile fields configured by the Institution);

• contact and guardian data (address, email, telephone, parent/guardian details and emergency contacts);

• admissions, enrolment, programme, course, timetable, attendance, learning, library, placement and academic records;

• examination data including registrations, question-paper workflow metadata, marks, results, grading, transcripts, certificates and convocation records;

• fee, scholarship, payment-reference and finance-related institutional records (MasterSoft does not require card credentials unless a separately contracted payment service expressly provides for them);

• faculty, employee, HR, payroll, leave, service-book and institutional administration data where relevant modules are used;

• account, role, authentication, audit, device, IP, access and security logs generated through use of the Services;

• documents, communications and other information uploaded or generated by Institution-authorised users; and

• special-category data only where the Institution elects to process it through relevant functionality and has an applicable legal basis.

Institutional Data is provided by the Institution, its authorised users, approved integrations or systems acting under the Institution's direction. MasterSoft does not independently solicit Institutional Data for unrelated purposes.

4.2 MasterSoft Controller Data

For its own business operations, MasterSoft may collect business contact details, enquiry or support metadata, contract and billing-contact information, website/device technical data, event or marketing preferences, recruitment data and records needed to comply with law or protect MasterSoft systems.

5. MasterSoft as Controller for its own business data

Where MasterSoft acts as Controller, it processes personal data only where a lawful basis applies. Depending on the activity, this may include performance of or steps toward a contract, compliance with legal obligations, MasterSoft's legitimate interests in operating and securing its business, or consent where consent is legally required.

MasterSoft may use Controller Data to respond to enquiries, administer customer and vendor relationships, manage contracts and accounts, maintain security, prevent misuse, recruit personnel, comply with law, and communicate about MasterSoft services where permitted. Data subjects may opt out of direct marketing communications at any time.

MasterSoft does not use Institutional student or employee data as a marketing list. Institutional Data is not sold, rented or disclosed to data brokers.

Where MasterSoft relies on consent as Controller, consent will be freely given, specific, informed and unambiguous, and may be withdrawn without affecting processing lawfully carried out before withdrawal.

Controller Data may be obtained directly from the individual, from the individual's Institution or employer, from service providers used for the relevant interaction, from public professional sources where lawful, and from website or device interactions. MasterSoft may disclose Controller Data to contracted service providers, professional advisers, auditors, payment or communication providers where relevant, and competent authorities where necessary and lawful. International transfers of Controller Data are handled in accordance with Section 13 where GDPR transfer rules apply.

MasterSoft retains Controller Data only for as long as reasonably necessary for the stated purpose, the contractual or business relationship, legal and regulatory obligations, dispute handling, security records or other legitimate recordkeeping needs, after which it is deleted or anonymised in accordance with applicable retention requirements. Where particular business-contact data is necessary to enter into or administer a contract or respond to a request, failure to provide it may prevent MasterSoft from completing that activity.

6. MasterSoft as Processor for Institutional Data

MasterSoft processes Institutional Data only:

• on documented instructions of the Institution, including the Service Agreement, Order Form, Purchase Order incorporating applicable data terms, configuration choices, authorised support requests and lawful written instructions;

• as necessary to provide, configure, host, secure, monitor, maintain, back up, recover, integrate and support the Services;

• to comply with law applicable to MasterSoft, in which case MasterSoft will inform the Institution before processing unless the law prohibits such notice; and

• through authorised subprocessors subject to data-protection obligations appropriate to the Services.

If MasterSoft reasonably believes an instruction infringes GDPR or other applicable data-protection law, MasterSoft may notify the Institution and, where legally appropriate, suspend the affected instruction while the parties resolve the issue.

MasterSoft does not claim ownership of Institutional Data. The Institution retains control over the purposes, user access, records and lawful retention of that data, subject to applicable law and contract.

7. Lawful basis, instructions and consent

7.1 Institution determines lawful basis

The Institution, as Controller, is responsible for identifying and documenting an Article 6 GDPR lawful basis for its processing and, where relevant, an Article 9 condition for special-category data. Depending on the Institution and jurisdiction, lawful bases may include legal obligation, public task, contract, legitimate interests or consent. MasterSoft does not prescribe consent as the default lawful basis for education administration.

7.2 Purchase Orders and agreements

A Purchase Order, Order Form or Service Agreement is not the consent of a student, child, parent, guardian or employee. It is a commercial and processing instruction between the Institution and MasterSoft. Where it expressly incorporates this Policy/DPA or equivalent data-processing terms, it may form part of the Controller's documented instructions to MasterSoft.

7.3 Consent where the Institution relies on it

Where the Institution chooses or is required to rely on consent, the Institution is responsible for obtaining, recording and managing that consent and for providing legally required privacy information. MasterSoft will reasonably assist the Institution in implementing withdrawals, restrictions or deletions communicated through authorised channels, subject to legal and technical constraints.

8. Children and minors

MasterSoft primarily provides enterprise education technology to Institutions. The Services are not designed as an independent consumer service in which MasterSoft determines why children's data is collected. Where an Institution enables accounts or processing for children or minors, MasterSoft processes that data solely on behalf of the Institution.

8.1 No automatic requirement for separate MasterSoft parental consent

The presence of a child's personal data in an institutional ERP does not, by itself, require MasterSoft to obtain a separate parent or guardian consent. The Institution, as Controller, determines the lawful basis for the educational processing and is responsible for any consent or parental authorisation that applicable law requires.

8.2 Article 8 GDPR

Where the Institution relies on consent under Article 6(1)(a) GDPR in relation to an information-society service offered directly to a child, Article 8 may require consent or authorisation from the holder of parental responsibility below the applicable Member State age threshold. The GDPR default threshold is 16 years and Member States may set a lower threshold, not below 13 years. The Institution is responsible for determining the applicable threshold and making reasonable efforts to verify parental authorisation where Article 8 applies.

8.3 Purpose and safeguards for children

• Children's data is processed only for legitimate institutional purposes such as admissions, enrolment, teaching, attendance, examinations, results, fees, communication, safeguarding or other authorised education administration.

• MasterSoft does not use children's Institutional Data for independent marketing, behavioural advertising, data brokerage or training of general-purpose AI models.

• Information that the Institution directs specifically to children should be clear, concise and age-appropriate where required by law.

• Requests by children, parents or guardians relating to Institutional Data are ordinarily routed to the Institution; MasterSoft assists the Institution in responding.

• Where the Institution configures higher-risk processing involving children, it remains responsible for assessing whether a Data Protection Impact Assessment or additional safeguards are required.

9. Special-category and sensitive data

MasterSoft does not require special-category data as a condition of using the core ERP unless a particular module or institutional process requires it. If an Institution chooses to process health, disability, religious data, biometric data used for uniquely identifying a person, or other Article 9 special-category data through the Services, the Institution is responsible for identifying an applicable Article 9 condition, providing required notices and applying appropriate access controls.

Where biometric devices or identity systems are integrated, MasterSoft processes resulting data only as specified by the Institution and the relevant integration. Biometric data is treated as Article 9 special-category data where it is processed for the purpose of uniquely identifying a natural person. Criminal-offence data, if any, may be processed only under lawful Controller instruction and applicable Article 10 requirements.

10. Purpose limitation; prohibited independent uses

MasterSoft will not, in relation to Institutional Data:

• sell, rent or broker the data;

• use the data to create independent advertising profiles or target data subjects with unrelated advertising;

• use identifiable Institutional Data to train general-purpose artificial-intelligence or large-language models for MasterSoft's or a third party's independent purposes;

• disclose the data to third parties except as instructed by the Institution, through authorised subprocessors, or where required by law; or

• combine Institutional Data across customers to identify or profile individual students, employees or parents for unrelated purposes.

MasterSoft may generate aggregate service-operational statistics only where the information does not contain personal data and cannot identify an Institution or individual, or where the Institution has expressly instructed or authorised the relevant processing.

11. Authorised access, confidentiality and support

Access to Institutional Data is role-based and limited to personnel and authorised subprocessors who need access to perform the Services. Persons authorised to process personal data are subject to confidentiality obligations and appropriate security policies.

Support access is performed only where reasonably necessary to investigate a reported issue, perform authorised implementation or maintenance, respond to a security event, recover service or comply with lawful obligations. Support access to Institutional Data hosted on Microsoft Azure is approved, time-limited, logged and subject to masking or pseudonymisation, and does not change the hosting region, as described in Sections 11.1 to 11.6 below.

Institutions must not share passwords or privileged credentials unnecessarily. ERP credentials, private links, database details or confidential Institutional Data must not be submitted to public AI/LLM services or unauthorised third-party testing platforms.

11.1 Scope and default approach

Sections 11.1 to 11.6 apply whenever MasterSoft personnel or subprocessor personnel access Institutional Data remotely or on site for support, implementation, maintenance, security or recovery purposes, including access from India. They supplement, and do not replace, the applicable Chapter V transfer mechanism. They do not restrict automated processing needed to operate the Services, such as hosting, backup and recovery, under the Institution's documented instructions.

Institutional Data is hosted on Microsoft Azure in the region selected for the Institution (see Section 13). Support access is designed so that Institutional Data stays in that region: support personnel work with the data in place, through controlled access to the Azure environment, rather than by taking copies. Wherever practicable, support is delivered without access to the content of Institutional Data, using system metadata, error logs, diagnostic output, screen-sharing sessions controlled by the Institution's own users, and masked, pseudonymised or synthetic data. Access to the content of Institutional Data in a production environment is permitted only where necessary for the task and in accordance with Sections 11.2 to 11.5.

11.2 Institution approval and notification

Before MasterSoft accesses the content of Institutional Data in a production environment for a support or implementation task, MasterSoft will obtain the approval of the Institution's authorised contact named in the Agreement or onboarding records. The approval will be recorded in the support ticket or another written or electronic form and will state the purpose, the data or modules concerned and the period of access. The Institution may give standing approval for defined categories of routine tasks and may withdraw or narrow any approval at any time.

Where access is necessary to respond to a security event or to restore availability and prior approval cannot reasonably be obtained, MasterSoft may proceed using the minimum access needed. MasterSoft will then notify the Institution's authorised contact without undue delay, and in any event within 24 hours after access begins, stating the reason, the data or systems concerned and the actions taken, unless law prohibits the notice.

The Institution may, by written instruction, require approval for additional categories of data or modules (for example data relating to health or disability, or biometric data) or restrict support access to defined modules.

Where Microsoft personnel need access to content in a MasterSoft Azure environment that holds Institutional Data, MasterSoft will use the customer-approval controls offered by Microsoft for the Azure services concerned, such as Customer Lockbox where available, so that each request is reviewed by MasterSoft before access is granted. Microsoft's own access is otherwise governed by Microsoft's data protection terms and Section 12.

11.3 Time-limited and least-privilege access

MasterSoft will apply the following controls to support access to Azure production environments that contain Institutional Data:

• no standing access by support personnel to the content of Institutional Data; elevated roles are activated only on request, for a specific ticket, task and role (just-in-time access), using Azure privileged-access controls such as Microsoft Entra Privileged Identity Management or an equivalent;

• credentials and elevated privileges are time-limited and expire automatically when the task ends and in any event within 24 hours, unless the Institution approves a longer period in writing;

• multi-factor authentication is required for all remote access to Azure production environments;

• access is made only from managed, security-controlled devices through a secure access gateway hosted in the Institution's Azure region (such as Azure Bastion or a virtual desktop), and production databases and storage are not directly reachable by support personnel from the public internet;

• download, clipboard copy and file transfer from gateway sessions are disabled by default, and Institutional Data is not stored on personal or unmanaged devices, or in email, chat or ticketing tools, except where the Institution has approved it for a specific task; and

• support access rights are reviewed at least quarterly and removed promptly on a change of role or departure.

11.4 Access logging and Institution visibility

MasterSoft will log each support access to Institutional Data in Azure production environments, using Azure identity, activity and audit logging (for example Microsoft Entra sign-in and audit logs, Azure Activity Logs and Azure Monitor, and database auditing where enabled), together with MasterSoft's ticket and approval records. The logs will record at least the identity of the person accessing, the date, time and duration, the ticket reference and stated purpose, the systems or modules accessed, the type of action (for example view, modify, export or delete), the approving Institution contact, and the country from which access was made.

Logs that contain Institutional Data or personal data of the Institution's users will be stored in the Institution's Azure region, protected against unauthorised alteration, and retained for at least 12 months, or longer where the Agreement or applicable law requires. On the Institution's written request, MasterSoft will provide a report of support access to that Institution's environment within 10 business days, and without undue delay where the request relates to a suspected Personal Data Breach, a regulator enquiry or an audit under Part B. MasterSoft may redact information that relates to other customers or would compromise security.

11.5 Pseudonymisation and masking

MasterSoft will keep non-production environments separate from production and will use masked, pseudonymised or synthetic data in them for development, testing, training, troubleshooting and demonstrations. Production Institutional Data will not be copied to a non-production environment unless the Institution instructs this in writing, and then only after direct identifiers and sensitive fields have been masked or pseudonymised, unless doing so would defeat the purpose of the task. Any non-production environment that holds Institutional Data will be hosted in the Institution's Azure region.

Where support personnel must view production records, MasterSoft will configure support views to mask by default fields such as government-issued identifiers, bank or payment references, contact details, health or disability information and biometric templates, using database-level masking (such as Azure SQL Dynamic Data Masking) or equivalent application-level masking, and will unmask a field only where needed for the approved task. Masking is applied in addition to, and not instead of, the access controls in Section 11.3. Special-category data, including biometric templates, will be accessed only where strictly necessary and where the approval under Section 11.2 expressly covers it.

Data in support or diagnostic extracts will be pseudonymised where practicable and deleted when the task closes, and in any event within 30 days.

11.6 Hosting region, access locations and relationship to other terms

Support access does not change the hosting region. Institutional Data at rest, including backups and disaster-recovery copies, remains in the region and any secondary region described in Section 13. Remote access from India to an Azure environment hosted elsewhere is subject to Section 13 and the transfer mechanism applied between the parties. MasterSoft will not provide support access to Institutional Data from any country other than India, the hosting region and the locations of authorised subprocessors disclosed under Section 12 without first notifying the Institution. These safeguards do not limit the Institution's audit rights under Part B or its rights under any applicable SCCs. Where the Agreement or a signed DPA contains stricter terms, those terms prevail.

12. Subprocessors and third parties

MasterSoft may engage subprocessors for functions such as cloud hosting, infrastructure, backup/disaster recovery, communications, security, content delivery, monitoring and specialised support. MasterSoft remains responsible for imposing data-protection obligations on subprocessors that are no less protective, in substance, than the obligations applicable to the relevant processing.

Where Article 28(2) GDPR applies, the Institution provides general written authorisation for subprocessors through the Agreement/DPA, subject to the notification and objection process in Schedule 3 or any customer-specific terms. MasterSoft will maintain information about material subprocessors appropriate to the Services.

MasterSoft may disclose personal data where required by applicable law, court order or binding governmental request. Where legally permitted, MasterSoft will notify the Institution before disclosure and will disclose no more data than is legally required.

13. International transfers and data location

The hosting region for an Institution will be the region agreed in the Order Form, Service Agreement or service configuration. MasterSoft is established in India, and authorised support, security or service operations from India may constitute an international transfer or remote access to personal data even where the primary cloud environment is located in Europe.

MasterSoft hosts Institutional Data on Microsoft Azure in the Azure region selected for the Institution. MasterSoft stores Institutional Data at rest, including backups and disaster-recovery copies, only in that region and in any secondary region identified in the Order Form, Service Agreement or service configuration. MasterSoft will not move or replicate Institutional Data to a different region without prior written notice to the Institution and, where the move would be a restricted transfer, an applicable Chapter V mechanism. Remote access from India does not change the hosting region but may constitute a transfer, as described in this Section.

Where GDPR Chapter V restricts a transfer of personal data from the EEA to a country not covered by an applicable adequacy decision, the parties will implement an appropriate transfer mechanism. This may include the European Commission's 2021 Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), typically Controller-to-Processor Module Two for an EEA Controller transferring to MasterSoft as Processor, or another legally valid mechanism appropriate to the parties' roles.

Where required, MasterSoft will cooperate with the Institution on transfer impact assessments and supplementary contractual, technical or organisational measures. No statement in this Policy should be interpreted as treating India as an EU-adequate jurisdiction unless and until an applicable adequacy decision exists.

Remote access to Institutional Data from India is subject to the safeguards in Section 11. MasterSoft treats those safeguards as supplementary technical and organisational measures that apply in addition to, and not instead of, the applicable transfer mechanism.

Where a particular MasterSoft processing activity falls within GDPR Article 3(2) and Article 27 requires a representative in the Union, MasterSoft will designate an EU representative and make the representative's contact details available through the applicable privacy notice, contract or other appropriate channel.

14. Security of processing

MasterSoft maintains risk-based technical and organisational measures designed to provide a level of security appropriate to the nature of the Services and the risks to individuals. Measures are reviewed and improved as technology, threats and regulatory expectations evolve.

Depending on the contracted service and architecture, measures include:

• identity and access management, least-privilege roles, strong authentication and multi-factor authentication for privileged or designated access;

• support access to Institutional Data hosted on Azure that is approval-based, just-in-time, time-limited and logged, with masking or pseudonymisation of Institutional Data in support and non-production use, as described in Section 11;

• encryption in transit using current industry-standard protocols and encryption at rest where supported by the relevant service architecture;

• network security controls, firewalls/WAF, anti-malware, vulnerability management, secure configuration and periodic security testing;

• logging, monitoring and incident-response processes appropriate to production systems;

• segregation of customer access through application, logical and database controls appropriate to the deployment model;

• backup, restoration, disaster-recovery and business-continuity controls;

• secure development, change management, release controls and code/database access restrictions;

• confidentiality obligations, security awareness, access review and offboarding controls for personnel; and

• physical and environmental protections for MasterSoft-controlled facilities and reliance on cloud-provider controls for cloud data centres.

MasterSoft's information-security programme is maintained with reference to recognised security frameworks and its applicable ISO/IEC 27001:2022 certification scope and contractual commitments. Security descriptions do not create a guarantee that incidents can never occur; GDPR requires measures appropriate to risk rather than absolute security.

15. Data retention, return, deletion and backups

15.1 Institutional retention

The Institution determines how long Institutional Data is required for admissions, examinations, transcripts, certificates, HR, finance or other statutory and academic purposes. Some academic or credential records may lawfully require long retention. MasterSoft does not independently shorten or extend those Controller-defined periods except as required by law, security, contractual exit procedures or documented backup cycles.

15.2 End of service

At the end of the Services, MasterSoft will, at the Institution's choice and subject to the Agreement, return/export or delete Institutional Personal Data, unless applicable law requires continued storage. The Institution is responsible for requesting and validating any required export within the applicable exit period.

15.3 Backups and archives

Operational and disaster-recovery backups may retain copies of Institutional Data for a limited period after deletion from the active environment. Such residual copies are retained solely for resilience, disaster recovery, security and legal continuity; they are not restored for ordinary business use except where necessary for recovery or authorised investigation. Backup copies remain protected and are deleted or overwritten according to MasterSoft's documented backup-retention cycle and contractual commitments.

Where immediate deletion from a backup is technically impracticable without affecting backup integrity or other customers, MasterSoft may isolate the data from ordinary use and allow it to expire through the normal protected backup lifecycle, provided no incompatible use is made of it.

16. Data subject rights

16.1 Where MasterSoft is Processor

The Institution is responsible for responding to requests to access, rectify, erase, restrict, object, receive portable data or exercise other GDPR rights in relation to Institutional Data. If MasterSoft receives such a request directly and can identify the relevant Institution, MasterSoft will ordinarily route the request to that Institution and will not independently decide the request unless required by law.

Taking into account the nature of processing, MasterSoft will provide reasonable technical and organisational assistance to enable the Institution to fulfil its obligations, including search, export, correction, restriction or deletion where technically applicable and contractually authorised.

16.2 Where MasterSoft is Controller

Where MasterSoft is Controller, individuals may contact [email protected] to exercise applicable rights, including access, rectification, erasure, restriction, data portability and objection, subject to the conditions and exemptions in the GDPR. Individuals may object at any time to direct marketing. Where processing is based on consent, consent may be withdrawn at any time without affecting the lawfulness of processing before withdrawal (see Section 16.3). MasterSoft may need to verify identity before acting on a request.

Individuals also have the right to lodge a complaint with the competent data-protection supervisory authority, in particular in the Member State of their habitual residence, place of work or place of the alleged infringement. In MasterSoft's own Controller capacity, MasterSoft does not ordinarily make decisions based solely on automated processing that produce legal or similarly significant effects on individuals; if such processing is introduced, the required notice and safeguards will be provided.

16.3 Right to withdraw consent

Where personal data is processed on the basis of consent (Article 6(1)(a) GDPR) or, for special-category data, explicit consent (Article 9(2)(a) GDPR), the individual has the right to withdraw that consent at any time. Withdrawal does not affect the lawfulness of processing carried out on the basis of consent before it was withdrawn. Individuals are informed of this right before consent is given, and withdrawing consent will be as easy as giving it.

Where MasterSoft is Controller:

• Individuals may withdraw consent by emailing [email protected] or, where provided, by using an unsubscribe link, preference centre or cookie settings. MasterSoft may need to verify identity before acting on a request sent by email.

• MasterSoft will stop the processing that relied on consent without undue delay and will confirm this to the individual.

• Where consent was the only lawful basis, MasterSoft will delete or anonymise the related personal data, unless the law requires or permits it to be retained, for example to comply with a legal obligation or to establish, exercise or defend legal claims.

• Withdrawing consent will not result in any penalty or detriment, although MasterSoft may no longer be able to provide optional features, communications or services that depend on that consent.

Where MasterSoft is Processor: consent for Institutional Data is collected and managed by the Institution as Controller (see Section 7.3). Individuals should send withdrawals to the relevant Institution. If MasterSoft receives a withdrawal directly and can identify the Institution, it will route the request to the Institution and will not independently decide it. MasterSoft will reasonably assist the Institution in implementing any withdrawal, restriction or deletion that the Institution communicates through authorised channels, subject to legal and technical constraints.

Where consent was given by the holder of parental responsibility under Article 8 GDPR, it may be withdrawn in the same way by the holder of parental responsibility or by the individual once they reach the applicable age.

17. Personal data breaches

MasterSoft maintains incident-response procedures for suspected or confirmed security incidents. Where MasterSoft becomes aware of a Personal Data Breach affecting Institutional Data, it will notify the Institution without undue delay and provide available information reasonably necessary for the Institution to assess its regulatory obligations.

MasterSoft will reasonably assist the Institution with investigation, containment, remediation, documentation and information required for notifications to a supervisory authority or affected individuals. The Institution, as Controller, remains responsible for determining whether notification is required and, where Article 33 applies, for meeting the applicable 72-hour supervisory-authority timeline.

A security event that does not involve personal data or does not meet the GDPR definition of a Personal Data Breach may be handled under the security-incident provisions of the Agreement or SLA.

18. DPIAs, regulatory cooperation and records

MasterSoft will provide reasonable information and assistance, taking into account the nature of processing and information available to MasterSoft, for Data Protection Impact Assessments and prior consultation where the Institution determines these are required under Articles 35 and 36 GDPR.

MasterSoft maintains records of categories of processing carried out on behalf of Controllers to the extent required by Article 30(2) GDPR and cooperates with competent supervisory authorities as required by applicable law.

MasterSoft will make information necessary to demonstrate compliance with applicable Article 28 obligations available to the Institution and support reasonable audits in accordance with Part B. Audit rights are implemented in a manner that protects other customers, confidentiality, system security and service availability.

19. Automated decision-making, analytics and AI

The Services may automate calculations, validations, workflows, attendance rules, grading logic, eligibility criteria, alerts or reports configured or authorised by the Institution. MasterSoft does not independently determine the academic or employment consequences of those outputs.

Where an Institution uses the Services for a decision that may fall within Article 22 GDPR or for profiling, the Institution is responsible for determining the legal basis, transparency, human review and safeguards required by law. MasterSoft will provide reasonable assistance regarding the functioning of the contracted technology.

Institutional Personal Data will not be used by MasterSoft to train a general-purpose AI/LLM model for independent purposes. Any AI-enabled feature that requires processing of Institutional Data must be covered by the applicable contract, documented instruction, security review, subprocessor/transfer safeguards and the Institution's lawful basis.

20. Cookies, logs and service telemetry

MasterSoft websites and Services may use strictly necessary cookies, session identifiers and comparable technologies for authentication, security, preferences, load management and service operation. Optional website analytics or marketing cookies will be used only as permitted by applicable law and, where required, after valid consent.

ERP security and operational logs may record account identifiers, timestamps, IP addresses, device/browser information, activity events and error data needed to operate, troubleshoot and secure the Services. Such information is not used to create unrelated advertising profiles of Institution users.

21. Institution responsibilities

Each Institution using the Services is responsible for:

• determining and documenting lawful bases for processing and any Article 9 conditions;

• providing privacy notices to students, parents, staff and other data subjects where required;

• obtaining and recording any consent or parental/guardian authorisation required by applicable law;

• ensuring the data entered into the Services is relevant, lawful and reasonably accurate;

• configuring user roles and access permissions appropriately and promptly removing access when no longer required;

• protecting credentials and preventing unauthorised sharing, scraping, security testing or disclosure to public AI/LLM services;

• defining retention periods, approving exports and communicating deletion or restriction instructions;

• handling data-subject requests and regulatory notifications as Controller; and

• ensuring its use of integrations, third-party applications and exported data complies with applicable law.

22. Policy governance and contact

This Policy is reviewed periodically and may be updated to reflect legal, regulatory, technical, security or service changes. Material changes affecting contracted processing will be communicated in accordance with the applicable Agreement/DPA. A privacy-policy update does not convert processing that requires consent into consent merely by continued use.

Questions, Controller instructions and privacy requests may be directed to:

Part B: Institutional Data Processing Terms

Article 28 GDPR – Controller / Processor Framework

These terms apply where an Institution and MasterSoft incorporate them into a binding Service Agreement, Order Form, Purchase Order or other contract. "Controller" means the Institution and "Processor" means MasterSoft for the Institutional Personal Data covered by that contract. If a separately signed DPA applies, it supersedes these terms to the extent of conflict.

B1. Subject matter and duration

MasterSoft will process Institutional Personal Data for the subject matter, nature, purposes and duration described in the Agreement and Schedule 1. Processing continues for the service term and any limited exit, legal-retention and backup-expiry period required to return, delete or protect the data.

B2. Documented instructions

MasterSoft shall process Institutional Personal Data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country, unless processing is required by Union or Member State law to which MasterSoft is subject. In that case, MasterSoft shall inform the Controller of that legal requirement before processing, unless such law prohibits the information on important grounds of public interest. Where MasterSoft receives a binding request under the law of a third country, it will address that request in accordance with applicable law and the relevant Chapter V transfer mechanism, including the SCCs where used.

The Agreement, incorporated Order Form/PO, configuration selected by authorised Controller administrators, support tickets and authorised written requests constitute documented instructions to the extent consistent with applicable law and these terms.

B3. Confidentiality

MasterSoft shall ensure that persons authorised to process Institutional Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality and receive privacy/security guidance appropriate to their role.

B4. Security

MasterSoft shall implement appropriate technical and organisational measures under Article 32 GDPR, taking into account the state of the art, costs of implementation, nature, scope, context and purposes of processing, and risks to the rights and freedoms of natural persons. Current baseline measures are summarised in Schedule 2.

B5. Subprocessors

The Controller grants MasterSoft general written authorisation to engage subprocessors necessary to provide the Services. MasterSoft shall impose data-protection obligations on subprocessors by contract as required by Article 28(4) GDPR and remains responsible to the Controller for the performance of those obligations.

MasterSoft shall provide the Controller with information about intended material changes concerning addition or replacement of subprocessors in accordance with Schedule 3 or the Agreement, thereby giving the Controller an opportunity to object on reasonable data-protection grounds. If the parties cannot resolve a substantiated objection, the contractual remedies in the Agreement apply.

B6. Assistance with data subject rights

Taking into account the nature of processing, MasterSoft shall assist the Controller through appropriate technical and organisational measures, insofar as reasonably possible, to fulfil the Controller's obligations to respond to requests for exercising data-subject rights under Chapter III GDPR.

B7. Compliance assistance

Taking into account the nature of processing and information available to MasterSoft, MasterSoft shall reasonably assist the Controller with obligations under Articles 32 to 36 GDPR, including security, breach assessment, DPIAs and prior consultation where applicable.

B8. Personal Data Breach notification

MasterSoft shall notify the Controller without undue delay after becoming aware of a Personal Data Breach affecting Institutional Personal Data and shall provide available details reasonably required under Article 33(3) GDPR, which may be supplied in phases as information becomes available. MasterSoft will take reasonable steps within its control to contain and remediate the breach.

B9. Return and deletion

At the Controller's choice, and subject to the Agreement, MasterSoft shall delete or return Institutional Personal Data after the end of the Services and delete existing copies, unless Union or Member State law requires storage. Any other legally compelled retention or disclosure will be handled in accordance with applicable law and, where relevant, the applicable Chapter V transfer mechanism. Protected backup copies may remain until expiry of the ordinary backup cycle where immediate granular deletion is technically impracticable, provided the data is isolated from ordinary use and remains subject to these protections.

B10. Information and audits

MasterSoft shall make available information reasonably necessary to demonstrate compliance with Article 28 obligations and allow for and contribute to reasonable audits or inspections by the Controller or an auditor mandated by the Controller, subject to reasonable notice, confidentiality, safety, security and non-disruption requirements.

The parties should ordinarily use current independent certifications/attestations, security summaries, questionnaires, architecture evidence and remote review before requiring an on-site audit. No audit authorises access to another customer's data, source code unrelated to the Controller, trade secrets beyond what is necessary, or destructive/intrusive testing.

Penetration testing, vulnerability scanning, automated attack simulation, credential testing, AI/LLM testing against the live ERP, or other active security testing by the Controller or its vendors is prohibited unless expressly authorised in writing by MasterSoft under an agreed scope, timing, method and safety plan. This restriction protects the availability, confidentiality and multi-tenant security of the Services and does not remove the Controller's Article 28 audit rights.

B11. International transfers

Where Institutional Personal Data is transferred from the EEA to MasterSoft or a subprocessor in a third country and no adequacy decision or other applicable derogation/mechanism covers the transfer, the parties shall implement an appropriate Chapter V safeguard. Where the European Commission's 2021 SCCs are used, the applicable module and annexes will be completed based on the parties' roles, and the SCCs prevail over conflicting terms.

B12. Unlawful instructions

MasterSoft shall immediately inform the Controller if, in MasterSoft's reasonable opinion, an instruction infringes GDPR or other applicable Union or Member State data-protection law. MasterSoft may suspend the affected processing where necessary to avoid an apparent violation while seeking clarification, except where law requires continued processing.

B13. Controller obligations

The Controller warrants that its instructions are lawful and that it has satisfied the Controller obligations applicable to the Institutional Personal Data, including lawful basis, transparency, data minimisation, special-category conditions, children's safeguards, retention, rights handling and appropriate authorisation of users. MasterSoft's performance of Processor obligations does not transfer these Controller responsibilities to MasterSoft.

B14. Liability and precedence

Liability between the parties arising from these terms is governed by the liability provisions of the applicable Agreement, except to the extent GDPR, the SCCs or other applicable law requires otherwise. Nothing in these terms limits a data subject's statutory rights or a supervisory authority's powers.

Schedule 1: Processing Details

Schedule 2: Technical and Organisational Measures

The exact controls depend on the deployment and contracted services. MasterSoft maintains a risk-based security programme that includes the following control families, subject to periodic review and improvement:

Governance & accountability: Information-security and privacy policies; defined ownership; risk assessment; internal review; applicable ISO/IEC 27001:2022 controls and contractual security requirements.

Access control: Role-based access, least privilege, privileged-access restriction, strong passwords, MFA where applicable, joiner/mover/leaver controls and periodic access review. Approval-based, just-in-time and time-limited support access using Azure privileged-access controls or an equivalent, MFA for remote production access and quarterly access review (Section 11.3).

Encryption & communications: HTTPS/TLS for data in transit and encryption-at-rest capabilities appropriate to the platform/cloud architecture; managed keys and secrets appropriate to risk.

Application & infrastructure security: Secure configuration, network controls, WAF/firewalls, vulnerability management, patching, code/database access restriction, change control and periodic security testing.

Logging & monitoring: Security and administrative logs, monitoring, alerting and investigation capabilities appropriate to the service architecture. Support-access logs (including Azure identity, activity and audit logs) record the person, time, ticket, purpose, action and access country, are stored in the Institution's Azure region, are retained for at least 12 months and are available to Institutions on request (Section 11.4).

Availability & resilience: Documented backups, restore testing, disaster recovery, business continuity, redundancy and capacity planning appropriate to contracted service levels.

Data location: Institutional Data is hosted on Microsoft Azure in the region selected for the Institution. Backups and disaster-recovery copies remain in that region or an agreed secondary region (Section 13).

Development lifecycle: Controlled development/test/release processes, segregation of environments where appropriate, review/testing and protection of production data. Non-production environments are separate from production and use masked, pseudonymised or synthetic data (Section 11.5).

Data handling: Purpose limitation, data minimisation, access restrictions, export/deletion procedures, protected backup lifecycle and secure disposal.

People security: Confidentiality obligations, awareness/training, role-based access, acceptable-use rules and access revocation on role change or exit.

Incident response: Security-incident identification, triage, containment, investigation, recovery, evidence preservation and Controller notification for applicable Personal Data Breaches.

Vendor security: Due diligence and contractual obligations for relevant subprocessors, including confidentiality, security and transfer safeguards.

Physical security: Controlled access to MasterSoft offices and reliance on contracted cloud providers for physical data-centre safeguards.

Schedule 3: Subprocessor Framework

MasterSoft may use subprocessors in the following categories where needed for the contracted service:

• cloud infrastructure, data-centre, database, storage and disaster-recovery providers (currently including Microsoft Azure, used in the region selected for the Institution);

• content delivery, DDoS mitigation, WAF, DNS and cybersecurity providers;

• email, SMS, messaging and notification providers selected or approved for the Institution;

• monitoring, observability, support and service-management providers with limited authorised access;

• payment or identity providers only where the Institution contracts/enables those functions; and

• specialist implementation, migration or support providers under confidentiality and data-protection obligations.

MasterSoft will maintain a current subprocessor list or other reasonable disclosure mechanism for material subprocessors. Where the Agreement provides a notice period for subprocessor changes, that agreed period applies. The Controller may object on substantiated data-protection grounds; the parties will work in good faith to address the concern without compromising service security or other customers.

Schedule 4: Regulatory Reference Points

This Policy is structured with particular reference to the following GDPR provisions and official EU guidance:

---