Kadya Privacy Policy

This Privacy Policy explains how Kadya Limited ("Kadya", "we", "us", or "our") collects, uses, stores, and protects personal data in connection with our website, Framework intake, pilot application flows, and software platform.

• Kadya Limited is registered in Ireland, Company No. 821911.
• Registered office: Apartment 26, The Grove, Moyglare Hall, Maynooth, Kildare, Ireland, W23 CK63.
• Website: https://kadya.co
• Email: [email protected]

For any data protection enquiries, please contact us at [email protected]. Our supervisory authority is the Irish Data Protection Commission.

Kadya is a business-to-business software service for operational assurance around recruitment delivery, including client requirements, supporting evidence, and AI oversight where applicable. It is intended for organisations and authorised business users, not for consumer or personal household use.

This policy covers data processed through our public website, Framework intake and pilot application flows, contact forms, authenticated product workspace, integrations, reports, exports, and support/offboarding operations.

Kadya is generally the controller for website visitor data, business contact data, pilot application data, account data, Framework intake submissions, and operational records we create for our own business administration.

Where a customer connects hiring systems or instructs Kadya to process recruitment, candidate, workflow, or evidence data inside its workspace, Kadya generally acts as a processor for that customer. The customer remains responsible for having the authority and lawful basis to provide or connect that data.

Account and Organisation Data

We process names, work email addresses, authentication identifiers, organisation details, role/title, workspace settings, governance contacts, billing contact details, VAT or tax details where entered, and audit records of product activity.

Authentication Data

Authentication and sessions are handled through Clerk. We store Clerk user identifiers in local member and audit records so the platform can authorize access and preserve accountability.

Recruitment and Candidate Data

When a customer connects an applicant tracking system through Merge, Kadya requests only the supported ATS objects needed for the current pilot workflows: applications, offers, jobs, and job interview stages. The active connector mapping is designed to exclude direct candidate names, email addresses, phone numbers, CVs, attachments, free-text screening answers, and download URLs.

Kadya stores minimized recruitment metadata such as source object type, status, stage or job references, timestamps, pseudonymous candidate/application/offer references, sync state, and review state. Candidate-linked references are pseudonymous, not anonymous.

Governance Workspace Data

The product stores client requirement records, evidence records, Action Center items, policy records, reports or PDFs, audit records, questionnaire responses, and review notes. Where applicable, it also stores AI Inventory records, capability states, risk classifications, and candidate notices generated in the workspace.

Framework Intake, Pilot and Contact Data

The public Framework Evidence Map intake processes work email, company name, document type, optional recruitment-system information, and business, tender, framework or operational documents submitted for manual review. Users are instructed to remove and not upload CVs, passports, PPS numbers, health information, Garda vetting records, or other candidate or worker personal documents. Pilot application and contact forms may process name, company, work email, message, source, team size, demo or pilot interest, and follow-up status.

Technical Data

We process technical request data needed to operate, secure, monitor, and rate-limit the service. Rate limiting uses Upstash and stores hashed IP/email-derived keys rather than raw values where implemented in the application.

We use personal data to:

• provide and secure the authenticated Kadya workspace;
• maintain client requirement, evidence, Action Center, policy, report, and audit records;
• maintain AI Inventory, review, classification, and oversight records where applicable;
• connect supported hiring tools and sync minimized workflow records;
• generate operational outputs such as candidate notices and reports where instructed;
• manually review submitted business documents and prepare the Framework Evidence Map;
• respond to contact enquiries and pilot applications;
• send transactional, product, and consented marketing communications;
• detect abuse, enforce rate limits, investigate errors, and protect the service; and
• support customer export, offboarding, retention, and deletion workflows.

The live candidate notice route generates notice text deterministically from customer workspace information such as the organisation name, configured governance contact, optional role title, and active AI capability states in the AI Inventory. It does not send live notice prompts to a model provider.

Kadya does not make hiring decisions, screen candidates, rank applicants, or decide whether a candidate should progress. Customers remain responsible for their hiring decisions and for reviewing any operational output produced by the platform.

Kadya uses Cookiebot for cookie consent management. Clerk uses cookies and related session storage for authentication. The application may use browser storage for product state, cookie preferences, and temporary client-side workflow state.

Some client code can emit events to analytics functions such as gtag or Plausible if those scripts are present in the runtime environment. No such analytics provider should be treated as active unless it is deliberately configured and disclosed.

We use the following providers to operate the current pilot service:

• Railway - hosting and application infrastructure.
• Supabase PostgreSQL and Storage - production database and the separate, private Framework intake environment.
• Clerk - authentication and session management.
• Merge EU cloud - supported ATS integration and sync.
• Resend - transactional and contact emails.
• Upstash - rate limiting.
• Cookiebot - cookie consent management.
• Cloudflare - Turnstile bot and abuse protection for the public Framework Evidence Map intake.
• Neo Mail - business email.

These providers may process personal data in the EU/EEA or other jurisdictions depending on their infrastructure, support model, and our configuration. Kadya relies on appropriate contractual and transfer safeguards where required. Provider backup, log, and residual retention periods depend on provider-controlled systems and are not stated here as exact deletion guarantees.

We keep personal data only for as long as needed for the purposes described in this policy, unless a longer period is required for legal, security, audit, dispute, or contractual reasons.

• Raw Framework Evidence Map intake files and their intake metadata are retained for approximately 30 days after successful completion of this free workflow. Incomplete uploads are normally removed after approximately 24 hours.
• Contact enquiries are retained for 12 months after the last correspondence unless they become part of an ongoing customer, business, or legal relationship.
• Pilot applications are retained for 12 months after the last activity or application decision unless the applicant becomes a customer.
• Marketing data is retained while the consent or marketing relationship remains active. We review inactive records around 24 months, stop marketing when consent is withdrawn or a person objects, and may retain minimal suppression data where necessary to honour an opt-out.

Ordinary customer workspace, account, configuration, client requirement, evidence, Action Center, policy, report, audit, and AI Inventory records where applicable are generally retained until workspace deletion, subject to any specific retention workflow described below.

Eligible candidate-linked records follow a six-month code-enforced purge process. This may tombstone or redact evidence records and hard-delete related candidate graph rows such as staged connector events, review rows, ingest records, and record-state rows. Hash-chain continuity may be preserved through minimal tombstone data.

Kadya includes an operator-assisted customer export and offboarding process. Export generation and delivery are recorded, and the implementation enforces a 30-day retrieval window before destructive workspace deletion can proceed.

Final workspace deletion hard-deletes tenant/customer content from the application database and retains only a minimal OrganizationDeletionRecord as a deletion proof. App deletion does not automatically establish deletion from provider-controlled backups, logs, or residual systems.

Kadya uses role-based access controls for the current single-user pilot, Clerk authentication, same-origin protections on state-changing routes, CSP and related security headers, encrypted Merge account tokens, redacted error logging, hashed rate-limit keys, and audit records for important workspace actions.

The public Framework Evidence Map uses private intake storage, restricted accepted file types and sizes, bot protection, and rate limiting.

No security system is perfect. Customers should use strong account security, limit access to authorised users, and tell us promptly about suspected misuse or security issues.

Depending on your circumstances and our role as controller or processor, you may have rights under GDPR to access, rectify, erase, restrict, port, or object to processing of your personal data. Where we act as processor for a customer, we may need to refer or coordinate your request with that customer.

To exercise rights, contact [email protected]. You may also contact the Irish Data Protection Commission at dataprotection.ie.

We may update this Privacy Policy as Kadya, our providers, or our legal obligations change. The latest version will be published on https://kadya.co.

Questions about this policy should be sent to [email protected].