Compliance & Data Processing Terms

Nasiya is a data controller in respect of personal data relating to account holders — i.e. the recruiters, HR managers, and administrators who register for and use the Nasiya platform. Nasiya determines the purposes and means of processing this data (authentication, billing, product communications, service improvement) and is directly responsible for its handling under applicable law.

Nasiya is a data processor in respect of candidate personal data submitted by customer organisations. This includes CV files, resume text, names, email addresses, phone numbers, AI-generated analysis outputs, interview notes, and pipeline stage data relating to third-party candidates. Nasiya processes this data only on the documented instructions of the customer.

Customer organisations are data controllers for all candidate personal data they submit to, or generate within, Nasiya. The customer determines the purpose of processing (evaluating candidates for employment), selects the candidates whose data enters the system, and makes the ultimate hiring decisions. This distinction matters: the customer bears primary responsibility under data protection law for the lawfulness of submitting candidate data, for informing candidates of AI processing where required, and for ensuring that Nasiya's outputs are not used in a discriminatory or otherwise unlawful manner.

Where a customer is a recruitment agency acting on behalf of employer clients, the allocation of controller, processor, and sub-processor roles between the agency, the employer client, and Nasiya depends on the nature of each engagement and the parties' contractual arrangements, and is not necessarily as described above for every party. See Section 19 of our Privacy Policy and any applicable Agency Partner Agreement, which govern over this general statement for agency engagements.

Nasiya engages sub-processors (listed in Section 8) who act as processors on Nasiya's behalf. Nasiya remains liable to customers for sub-processor compliance in the same manner as if Nasiya were performing the processing directly.

Nasiya will:

1. Process candidate personal data only on documented instructions from the customer, including with regard to transfers of personal data to a third country or international organisation, unless required to do so by applicable law (in which case Nasiya will inform the customer before processing, unless prohibited by law);
2. Ensure that all personnel authorised to process candidate personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
3. Implement and maintain appropriate technical and organisational measures to protect candidate personal data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access (see Section 9 for details);
4. Assist the customer, taking into account the nature of the processing and the information available to Nasiya, in fulfilling the customer's obligations to respond to data subject access, rectification, erasure, restriction, portability, and objection requests within 72 hours of receiving a forwarded request, to enable the customer to meet its own regulatory deadlines;
5. At the customer's choice, delete or return all candidate personal data to the customer after the end of the provision of the Service, and delete existing copies unless applicable law requires retention;
6. Make available to the customer all information necessary to demonstrate compliance with these obligations and allow for and contribute to audits and inspections conducted by the customer or an auditor mandated by the customer, subject to the conditions in Section 12;
7. Notify the customer without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting candidate data (see Section 10).

The customer will:

1. Ensure it has a lawful basis under applicable data protection law for submitting candidate personal data to Nasiya for AI-assisted processing;
2. Comply with its own obligations as a data controller under all applicable data protection, privacy, and AI legislation, including obligations in respect of automated decision-making and AI transparency;
3. Where required by applicable law, inform candidates that their personal data may be processed by AI systems as part of the recruitment process, and provide them with information about Nasiya's processing before submitting their data;
4. Submit only candidate data that it is lawfully entitled to submit; not submit special category or sensitive personal data unless it has a specific lawful basis and has documented that basis;
5. Ensure that Nasiya's AI outputs are used as decision-support tools and not as the sole basis for hiring, rejection, or other employment decisions.

Subject matter: AI-assisted evaluation of job candidates for employment purposes.

Duration: the term of the customer's subscription to Nasiya, plus the data deletion period set out in Section 11.

Nature and purpose: collection, storage, AI analysis (scoring, claim extraction, interview question generation, chat), display to authorised users, and deletion of candidate personal data.

Types of personal data: name, email, phone number, CV/resume content, AI-generated analysis outputs, notes, and pipeline stage data.

Categories of data subjects: third-party job candidates.

Nasiya processes candidate data as a processor under the customer's lawful basis. The customer, as data controller, is responsible for identifying and documenting a valid lawful basis before submitting candidate data to Nasiya. Common applicable bases include:

• Article 6(1)(f) — Legitimate interests: the customer's legitimate interest in evaluating candidates efficiently for open positions, provided that interest is not overridden by the candidate's rights and freedoms. Where this basis is relied on, customers should conduct and document a legitimate interests assessment (LIA).
• Article 6(1)(b) — Pre-contractual measures: where processing is necessary to take steps at the data subject's request prior to entering into an employment contract, applicable where the candidate has applied directly.
• Article 6(1)(a) — Consent: explicit, informed consent obtained from the candidate prior to processing. Customers relying on consent must ensure it meets the standards of Article 7 (freely given, specific, informed, unambiguous) and that withdrawal of consent is as easy as giving it.

Nasiya does not rely on any independent lawful basis for processing candidate data submitted by customers — Nasiya processes solely on the customer's instruction.

Nasiya's AI-generated scoring, tier classification, claim analysis, and risk assessments constitute automated processing of personal data that may produce outputs with significant effects on candidates in an employment context. This processing falls within the scope of Article 22(1) where it is used as the sole basis for a decision that produces legal or similarly significant effects for the candidate.

Nasiya's position: Nasiya's outputs are designed exclusively as decision-support tools for human recruiters. The platform does not automatically accept or reject candidates, send rejection communications, or take any action without human confirmation. However, customers are responsible for ensuring that, in their use of Nasiya:

• No hiring or rejection decision is based solely on Nasiya's automated output without meaningful human review, as required by Article 22(3);
• Candidates are informed of the existence of automated processing where required, including the logic involved, significance, and envisaged consequences (Article 13/14 transparency obligations);
• Candidates are provided with the right to request human review of any decision significantly affecting them and to express their point of view (Article 22(3)).

Customers operating high-volume screening workflows using Nasiya's bulk analysis features should pay particular attention to these obligations and may need to implement specific safeguards under Article 22(2)(c) if relying on explicit consent as their lawful basis for automated processing.

When a candidate exercises their data subject rights (access, rectification, erasure, restriction, portability, objection) in relation to data held on Nasiya, the customer as data controller bears the obligation to respond. Nasiya will assist customers as follows:

• Access requests (Article 15): Nasiya will provide the customer with a structured export of all personal data held in relation to the identified data subject within 72 hours of a forwarded request, to enable the customer to respond within the 30-day GDPR deadline.
• Erasure requests (Article 17): Nasiya will delete the data subject's record and associated AI analyses within 14 days of a verified instruction from the customer. Encrypted backup copies will be overwritten within 60 days.
• Portability requests (Article 20): Nasiya will export candidate data in JSON or CSV format on request.
• Rectification (Article 16) and restriction (Article 18): Nasiya will implement corrections or restrictions to active processing upon customer instruction.

Candidates wishing to exercise their rights should contact the recruiting organisation (the data controller) in the first instance. If the recruiting organisation is unresponsive, candidates may contact Nasiya at support@nasiya.co with the subject line “GDPR SAR”.

Under Article 35 GDPR, a Data Protection Impact Assessment is required before carrying out processing likely to result in high risk to the rights and freedoms of individuals, including systematic and extensive profiling with significant effects and large-scale processing of personal data. Systematic use of Nasiya to evaluate candidates at scale likely meets this threshold.

Customers using Nasiya in the EU for systematic evaluation of candidates should conduct a DPIA before or promptly after deployment. Nasiya will cooperate with DPIA processes on request, providing information about its processing activities, security measures, sub-processors, and data flows necessary to complete the assessment.

Annex III, point 4 of the EU AI Act identifies AI systems used for recruitment or selection of natural persons — notably for filtering applications, evaluating candidates, or making or influencing decisions — as high-risk AI systems. Nasiya, as an AI-powered candidate evaluation tool, is likely to fall within this category when deployed by EU-based organisations.

Under the EU AI Act:

• Nasiya (as provider) maintains technical documentation and implements appropriate accuracy, robustness, and cybersecurity standards for its AI models;
• Customer organisations acting as deployers under Article 3(4) of the AI Act bear obligations under Articles 26–29, including: designating a point of contact for AI Act compliance; conducting a fundamental rights impact assessment where required; ensuring human oversight is in place so that natural persons can intervene or override AI outputs; informing affected workers and candidates of AI use as required by Article 26(7) and applicable national law;
• Customers must not use Nasiya in a manner that bypasses the human oversight mechanisms built into the platform, as doing so would likely constitute non-compliant deployment of a high-risk AI system.

Nasiya will assist customers with their EU AI Act deployer obligations on request, including providing documentation of its AI system's capabilities, limitations, training data categories, and intended use cases.

For transfers of personal data from the UK to countries not covered by a UK adequacy regulation (including the United States, where several of Nasiya's sub-processors are based), Nasiya relies on International Data Transfer Agreements (IDTAs) as approved by the UK Information Commissioner's Office, or the UK Addendum to EU Standard Contractual Clauses, incorporated into its agreements with each sub-processor.

UK-based individuals who believe their data protection rights have been violated may lodge a complaint with the ICO at ico.org.uk. Nasiya will cooperate fully with any ICO investigation.

UAE customer organisations are data controllers (“personal data controllers” as defined in Article 1 UAE PDPL) for candidate personal data submitted to Nasiya. Nasiya acts as a personal data processor on behalf of such customers, processing data only on the customer's instructions and in accordance with this DPA.

Nasiya does not process special categories of sensitive personal data as defined in Article 1 UAE PDPL — which include health and medical data, genetic data, biometric data used for unique identification, financial data, criminal records, data revealing racial or ethnic origin, political opinions, religious beliefs, or data concerning sexual orientation — without explicit prior consent from the data subject or another specific legal basis under the PDPL.

Customer organisations must not submit such data to Nasiya unless they hold valid consent or a lawful basis under UAE PDPL and have notified Nasiya in advance. Nasiya reserves the right to refuse processing of sensitive data where appropriate legal grounds are not established.

Personal data of UAE data subjects is processed by Nasiya's sub-processors located in the United States and, in some cases, the European Union (see Section 8 — Sub-Processors). These transfers are effected under contractual protections designed to meet the standards required by the UAE PDPL for cross-border data transfers, including appropriate safeguards concerning the level of data protection in the recipient country.

Nasiya will assist UAE customer organisations in fulfilling the following data subject rights within the 30-day timeframe prescribed by UAE PDPL:

• Right of access (Article 6): the right to know what personal data is held and how it is processed;
• Right to correction (Article 7): the right to have inaccurate data corrected;
• Right to erasure (Article 8): the right to have personal data deleted, subject to lawful exceptions;
• Right to restriction of processing (Article 9): the right to restrict how data is used in certain circumstances;
• Right to object to automated decisions (Article 10): the right to object to decisions made solely on the basis of automated processing, including AI-generated evaluations. This mirrors and complements the Article 22 GDPR obligation described in Section 4.2.

In the event of a personal data breach affecting personal data of UAE data subjects, Nasiya will notify affected customer organisations within 72 hours of discovering the breach, consistent with the notification obligations under UAE PDPL. Notification will contain the information specified in Section 10 of this document.

When an Australian customer organisation discloses personal information about a candidate to Nasiya (an overseas recipient), APP 8.1 ordinarily requires the disclosing entity to take reasonable steps to ensure the overseas recipient does not breach the APPs in relation to that information. Nasiya contractually commits, under this DPA, to handling all personal information of Australian data subjects in accordance with the APPs. This commitment is a relevant factor an Australian customer organisation can take into account in forming its own reasonable belief under APP 8.2(a) — it does not, by itself, establish that exception. The customer remains responsible for assessing, on the facts of its own disclosure, whether Nasiya's handling is enforceable by the individual and substantially similar overall to the APPs, as APP 8.2(a) requires, or for taking its own reasonable steps under APP 8.1 if it does not rely on 8.2(a).

In the event of an eligible data breach (as defined under Part IIIC of the Privacy Act) involving the personal information of Australian individuals held by Nasiya, Nasiya will notify the affected Australian customer organisation within 72 hours of becoming aware of the breach. This notification will contain sufficient information to enable the customer to assess whether it must notify the Office of the Australian Information Commissioner (OAIC) and affected individuals under its own NDB obligations, and to prepare that notification if required.

Nasiya will not process sensitive information of Australian data subjects — as defined under section 6 of the Privacy Act (including health information, biometric data, racial or ethnic origin, religious beliefs, sexual orientation, and criminal record information) — without the express consent of the individual or another specific lawful basis under the Privacy Act. Customer organisations must not submit sensitive information to Nasiya without first obtaining appropriate consent and notifying Nasiya.

APP 12 (access) and APP 13 (correction) entitle Australian individuals to access and correct personal information held about them. Nasiya will assist customer organisations in fulfilling these requests within the timeframes required by the Privacy Act.

Australian individuals who believe their privacy rights have been breached may lodge a complaint with the Office of the Australian Information Commissioner at oaic.gov.au. Nasiya will cooperate with any OAIC investigation.

• Encryption in transit: TLS 1.2 or higher is enforced on all connections between clients and Nasiya servers. HTTP Strict Transport Security (HSTS) is enforced to prevent protocol downgrade attacks. Unencrypted connections are rejected.
• Encryption at rest: AES-256 encryption is applied to all database records and file storage (CV files, documents) hosted on Supabase (AWS infrastructure). Encryption keys are managed by Supabase/AWS Key Management Service.

• Role-based access control (RBAC): access within Nasiya is governed by organisational roles (admin, member). Users can only access data belonging to their own organisation.
• Row-level security (RLS): Nasiya's database tables carry PostgreSQL row-level security policies enforced at the database layer by Supabase. These policies independently govern the limited, lower-privilege client connections used for real-time updates. Most of Nasiya's backend operations, however, connect using a privileged service-role credential that is not subject to RLS; for those operations, multi-tenant isolation is enforced by server-side application logic — every backend request is authenticated and scoped to the requesting organisation before any query executes — rather than by RLS. Nasiya does not represent that RLS alone would prevent cross-organisation access for backend operations if that application-layer authorisation contained a defect.
• Minimum privilege: application service roles are granted only the minimum database permissions required for their function.
• Support access: Nasiya staff cannot access a customer's workspace for support purposes without an active, time-boxed access window that the customer has opened — default Read-Only, maximum 24 hours, revocable by the customer at any time. See Support Access Levels for exactly what each level permits.
• Administrative authentication: access to production infrastructure is restricted to authorised Nasiya personnel. Nasiya does not currently represent that multi-factor authentication (MFA) is enforced as a mandatory control on all administrative access. Organisations that require MFA as a contractual control should raise it in their Order Form or Enterprise Agreement.

• Extension API token hashing: Chrome extension API tokens are stored in the database exclusively as SHA-256 hashes. The raw token is displayed once at the moment of generation and is not stored by Nasiya. It cannot be retrieved or reconstructed.
• ATS credentials: third-party ATS API keys are stored encrypted; they are not exposed in plain text in any application response after initial entry.
• Secrets management: all application secrets, API keys, and environment variables are managed via secure environment variable injection and are never committed to source code repositories.

• WAF and DDoS protection: Cloudflare provides web application firewall and DDoS mitigation on all public-facing Nasiya endpoints.
• Bot protection: Cloudflare Turnstile is deployed on public candidate application forms to prevent automated abuse.
• Input sanitisation: all user-supplied input is sanitised before processing. Parameterised queries are used exclusively; raw SQL string interpolation is prohibited.
• AI prompt changes: changes to AI prompts are made by Nasiya's engineering team with the goal of preventing prompt injection and keeping outputs scoped appropriately. Nasiya does not currently require a second-person review of every prompt change before it ships.

• Automated vulnerability scanning: npm dependencies are monitored for known vulnerabilities via automated scanning. Critical vulnerabilities trigger immediate patching workflows.
• Version control: production code changes are tracked in version control (git). Nasiya does not currently require a second-person peer review of every production change before deployment; this is a control Nasiya expects to adopt as the team grows.

• Incident response plan: Nasiya maintains a written incident response plan covering detection, containment, eradication, recovery, and post-incident review.
• Security contact: the designated security contact is support@nasiya.co.
• 72-hour breach notification SLA: Nasiya commits to notifying affected customers within 72 hours of becoming aware of a breach (see Section 10).
• Backups: Nasiya's database is hosted on Supabase's managed Postgres infrastructure. Nasiya does not currently represent a specific backup frequency or point-in-time recovery guarantee. Organisations that require a specific backup/recovery SLA as a contractual control should raise it in their Order Form or Enterprise Agreement.
• Hosting resilience: Nasiya's infrastructure providers (Supabase, Vercel) operate the underlying hosting and database infrastructure. Nasiya relies on each provider's published resilience and availability capabilities, details of which are available directly from each provider.

Nasiya will notify affected customer organisations without undue delay, and in any event within 72 hours, of becoming aware of any personal data breach affecting candidate personal data processed on the customer's behalf — regardless of Nasiya's own assessment of the likely risk to individuals, consistent with a processor's unconditional notification duty to the controller under GDPR Article 33(2). It remains the customer's responsibility, as data controller, to assess whether the breach is likely to result in a risk to individuals' rights and freedoms and, if so, to notify the relevant supervisory authority and affected individuals within the applicable regulatory deadlines. Where Nasiya's notification to the customer cannot be completed within 72 hours, Nasiya will provide an initial notification within that period and follow with further details as they become available.

Breach notifications provided to customers will include, to the extent known at the time of notification:

• The nature of the personal data breach, including the categories and approximate number of data subjects affected;
• The categories and approximate number of personal data records affected;
• The name and contact details of Nasiya's data protection contact where further information can be obtained;
• A description of the likely consequences of the breach;
• A description of the measures taken or proposed to address the breach, including where appropriate measures to mitigate its possible adverse effects;
• The timeline of events, including when the breach was discovered and when it is believed to have begun.

Where a breach requires notification to a supervisory authority (under GDPR Article 33, UK GDPR, UAE PDPL, or the NDB scheme), or notification to affected individuals (under GDPR Article 34, NDB, or equivalent), Nasiya will provide the customer with all information necessary to make those notifications within the applicable regulatory deadlines. Nasiya will not make regulatory notifications on behalf of the customer without explicit instruction, as the customer (as data controller) bears the reporting obligation.

Customers who suspect a breach, or who become aware of suspicious activity in their Nasiya account, should report it immediately to: support@nasiya.co with the subject line “Breach Report”.

Within 30 days of account termination, subscription cancellation, or a written deletion request from the customer, Nasiya will:

• Permanently delete all candidate personal data from active database systems, including candidate profiles, AI analysis outputs, notes, and pipeline stage records;
• Delete all CV files and resume documents from file storage;
• Delete any organisation context data, prompt customisations, and org-specific settings associated with the customer account;
• Provide, on request, a full data export to the customer in JSON or CSV format prior to deletion, covering all candidate records associated with the account.

As an operational matter, candidate data is typically soft-deleted (hidden from the customer's workspace and excluded from active processing) immediately upon request or termination, with permanent purge from active systems completed within the 30-day period above. See Section 11.2 for backup retention.

Encrypted automated database backups are retained for up to 60 days following the deletion of active data, after which they are permanently overwritten in the normal backup rotation cycle. Backup retention is a security and recovery measure; Nasiya does not access backup data for any purpose other than disaster recovery.

Nasiya will provide written confirmation of deletion of active data to the customer within 7 days of completing the deletion process, on request. Requests for deletion confirmation should be sent to support@nasiya.co with the subject line “DPA Request”.

Aggregated, anonymised data that cannot reasonably be used to identify any individual — for example, aggregate usage statistics or anonymised benchmark data — is not subject to deletion obligations under this section and may be retained indefinitely by Nasiya for product improvement purposes.

Nasiya will make available to customers, upon written request, all information reasonably necessary to demonstrate compliance with the obligations of this DPA, including details of sub-processor agreements, security certifications where applicable, and a summary of technical and organisational security measures.

Nasiya will respond to standard security and data protection questionnaires (including vendor security assessments and enterprise procurement questionnaires) within 15 business days of receipt.

Any customer may request a formal compliance audit of Nasiya's data processing practices with 30 days' written notice, limited to once per 12-month period (or more frequently if required following a personal data breach notified under Section 10, or at the direction of a supervisory authority). This right reflects the customer's own audit and inspection right as data controller under GDPR Article 28(3)(h) and equivalent provisions in other applicable law, and is available regardless of subscription plan. Audits shall be conducted at the customer's expense and are subject to:

• Reasonable confidentiality obligations on the part of the auditor;
• Scheduling during normal Nasiya business hours;
• The auditor holding appropriate professional qualifications and not being a competitor of Nasiya;
• A scope agreed in advance that is limited to compliance with this DPA.

Business and Enterprise plan customers may instead be offered an expedited or dedicated audit process as a commercial benefit of their plan; this does not narrow the statutory right available to customers on any other plan.

Material changes to these terms will be communicated to account holders by email at least 14 days before the change takes effect. Where a change reduces the level of data protection afforded to candidates, Nasiya will also publish the updated terms at the URL of this page and will require affirmative acceptance from customers before the change applies to their account.

Where updates are required by changes in applicable law, regulatory guidance, or supervisory authority decisions, Nasiya may apply changes with shorter notice than 14 days. In such cases, Nasiya will explain in the notification the regulatory requirement driving the change.

Continued use of the Nasiya platform after the effective date of any updated version of these terms constitutes acceptance of the changes. Customers who do not accept material changes may terminate their subscription and request deletion of their data in accordance with Section 11.