Data Processing Agreement
Last Updated:
1. Scope and Roles
This Data Processing Agreement ("DPA") governs the processing of personal data
by Rilono on behalf of organizations that use Rilono Enterprise —
visa consultancies, agencies, and similar businesses that manage their own applicants through
the platform ("Organization," "you").
Processor role (the main subject of this DPA). For personal data relating to the
Organization's own applicants and to people named in their files ("Client Data"),
the Organization is the controller and Rilono is the processor.
Rilono processes Client Data only on the Organization's documented instructions, as set out in
Section 3 and Annex I.
Controller role (a separate relationship, described here for transparency).
Some data Rilono holds in connection with an Enterprise account is not Client Data and is
not processed on the Organization's instructions. Rilono is an independent
controller for that data and the Privacy Policy — not this DPA —
governs it. It comprises:
- The Organization's own business verification and settlement details collected for
Rilono Finance — legal business name, business type, business contact name,
email and phone, PAN, GSTIN, the last four digits of the settlement bank account, IFSC code,
beneficiary name, and the timestamp, version and IP address of the Organization's
service-delivery attestation (see Section 9).
- Accounts and sign-in data of the Organization's staff users, including
authentication records, consent records for the Terms & Conditions and Privacy Policy,
and sign-up attribution data.
- Platform operations data — AI usage metering (token counts, model, cost)
attributed to the Organization and the staff user who triggered the action, and
staff-facing abuse-control records such as rate-limit counters keyed to a
staff member's account or IP address. Abuse-control records generated by the Organization's
clients through client-facing links are Client Data and are dealt with in Annex I,
not here.
- Retained financial records. Where the Organization deletes a client record,
Rilono retains the associated payment records — including the client's name and the email
address the payment link was sent to — as its own accounting records, on the terms set out in
Section 13. Rilono determines that retention itself; it is not carried out on the
Organization's instruction, and for that residual processing Rilono is a controller relying
on its legal obligations under Indian accounting and tax law.
- Enquiries submitted through Rilono's public demo-request form.
This DPA does not apply to the Rilono consumer platform. Where an individual uses
Rilono directly as a student or applicant (the B2C product), Rilono is the controller
of that person's data and the Privacy Policy governs it. Nothing in this
DPA creates rights or obligations in respect of that relationship, and the technical measures
described in this DPA describe the Enterprise product only.
2. Definitions
- "Client Data" means personal data relating to the Organization's applicants
and to other individuals named in or derived from the Organization's files, which Rilono
processes on the Organization's behalf through Rilono Enterprise. Annex I sets out the
categories in detail.
- "Client" or "end client" means an applicant or other
individual whose record the Organization maintains in Rilono. Clients do not hold Rilono user
accounts; their records are created and controlled by the Organization's staff.
- "Data Protection Laws" means all laws applicable to the processing of Client
Data under this DPA, including India's Digital Personal Data Protection Act, 2023
("DPDP Act"), the EU General Data Protection Regulation 2016/679
("GDPR") and the UK GDPR, in each case to the extent they apply.
- "controller," "processor," "personal data," "processing," "data subject" and
"personal data breach" have the meanings given in the GDPR; where the DPDP
Act applies, "Data Fiduciary" and "Data Processor" are read as controller and processor
respectively.
- "Sub-processor" means a third party engaged by Rilono to process Client
Data. Annex II is the current register.
- "Standard Contractual Clauses" or "SCCs" means the standard
contractual clauses for the transfer of personal data to third countries adopted by the
European Commission in Implementing Decision (EU) 2021/914 and, for transfers subject to the
UK GDPR, the UK International Data Transfer Addendum issued under section 119A of the Data
Protection Act 2018.
- "Services" means Rilono Enterprise, including the web dashboard, the
client-facing portal and links described in Section 8, Rilono Finance, and the Rilono
Copilot browser extension.
3. Processing Instructions and Purpose
Rilono processes Client Data only on the Organization's documented instructions. The
Organization's instructions are: this DPA, the Terms & Conditions, the
configuration choices the Organization's staff make in the product, and any further written
instruction the parties agree. Rilono will inform the Organization if, in its opinion, an
instruction infringes Data Protection Laws.
Processing required by law. Rilono may process Client Data otherwise than on the
Organization's documented instructions where it is required to do so by a law to which Rilono is
subject. In that case Rilono will inform the Organization of that legal requirement
before processing, unless that law prohibits it from doing so on important
grounds of public interest.
Government and law-enforcement demands. Rilono is established in India and is
subject to Indian law, including the Information Technology Act, 2000 and the DPDP Act. If
Rilono receives a binding demand from a public authority — law enforcement, a regulator, a court
or a national-security body — for disclosure of Client Data, Rilono will:
- notify the Organization promptly, and where possible before disclosing anything, unless
legally prohibited from giving notice; where notice is prohibited, use reasonable efforts to
obtain a waiver of the prohibition and to inform the Organization as soon as it is permitted
to;
- challenge the demand where, on a reasonable assessment, it is unlawful, overbroad or does not
follow the applicable procedure, and, where a challenge is available, suspend disclosure
pending its outcome so far as the law allows;
- disclose only the minimum amount of Client Data that the demand actually requires; and
- keep a record of the demands it receives and provide the Organization, on written request,
with aggregate figures on those demands and how it responded.
These commitments mirror Clause 15 of the Standard Contractual Clauses. Rilono has not to date
published a transparency report; the aggregate figures above are provided on request.
The purposes for which Rilono processes Client Data are the delivery of the following features.
This list describes the processing surface as at the "Last Updated" date at the top of this
document; Section 15 governs how it changes:
- Client CRM and pipeline management — storing and organising applicant
records, assignment, priority and pipeline stage.
- Destination-aware case records — structured, per-stage case fields specific
to the destination country (for example SEVIS and DS-160 references for the United States,
CAS and GWF references for the United Kingdom, UCI and IRCC application numbers for Canada,
TRN and HAP identifiers for Australia, APS and blocked-account details for Germany, and AVATS
references for Ireland).
- Document storage — storing documents uploaded by the Organization's staff
and by clients themselves.
- AI document processing — extracting the text of each uploaded document,
validating it, extracting structured fields (name, date of birth, document number, issue and
expiry dates, country), cross-checking a document against the client's profile and their
other documents, and recording validation outcomes and red-flag explanations.
- Automated profile population — where an identity document validates
successfully, populating empty fields on the client's profile (name, date of birth,
nationality, passport number, passport expiry) from the extracted values, recording
differences as conflicts rather than overwriting existing values, and adding a note to the
client timeline attributed to "Rilono AI".
- Deep Scan — a whole-dossier AI audit that reviews the client's profile, case
records, document contents, staff notes, stored emails, university shortlist, mock-interview
results and payment records together, and produces a stored risk level, summary, findings and
checks-passed record retained as history.
- AI Copilot in the dashboard — an assistant scoped to the Organization's own
records, which reads those records and generates an answer but creates and alters no client
records.
- AI Copilot in the Rilono browser extension — see Section 10.
- AI mock visa interviews — conducted by staff on a client's behalf or by the
client directly through an emailed link, grounded in the client's own documents and staff
notes, producing a stored transcript, AI feedback and verdict. Staff notes are excluded from
the prompt on the client-facing path.
- Email — composing, sending and storing the Organization's outbound email to
its clients, including attachments (see Section 8). Rilono does not currently receive or
store clients' replies; the dormant inbound capability, and the notice Rilono will give
before activating it, are described in Section 8.
- Client portal — making a read-only case portal available to the
Organization's clients and reporting their engagement with it back to staff (see Section 8).
- Document requests — inviting clients to upload their own documents through a
secure link.
- Calendar, deadlines and reminders — recording case events and deadlines,
in-product staff notifications, and automated reminder emails to clients where staff enable
them.
- University shortlisting and Course Finder — generating and storing
university and course recommendations with AI rationale, competitiveness assessments and
estimated costs. Both features transmit client profile data to the AI sub-processor; Annex II
states exactly what is sent.
- Rilono Finance — raising payment requests to the Organization's clients and
recording collection, settlement, refund and dispute status (see Section 9).
- Service operation and support — hosting, backup, security monitoring, fault
diagnosis, and support requested by the Organization.
Restrictions Rilono accepts. Rilono will not sell Client Data, will not process
Client Data for its own unrelated commercial purposes, and does not use Client Data to
train Rilono-owned AI models. Client Data is not used for Rilono's marketing, is not
added to any Rilono marketing audience, and no analytics or advertising technology operates on
the Enterprise dashboard, the client portal or the payment page.
A limit on what Rilono can promise about AI providers. Client Data is transmitted
to the AI sub-processors named in Annex II, which process it under their own terms. Rilono's
no-training commitment above is a commitment about Rilono's own models. Rilono's AI
integration can operate through either Google Cloud Vertex AI or the Gemini API depending on how
the deployment is configured, and the applicable Google terms — including whether prompts and
responses may be used by Google to improve its services — differ between them. Rilono therefore
does not represent that Client Data is excluded from the AI provider's own model
training, and the Organization should treat that as an open point in its own assessment.
Annex II states the position in full.
4. Organization Responsibilities
The Organization is the controller of Client Data and is responsible for it. In particular:
- Lawful basis and notice. The Organization warrants that it has a valid
lawful basis, and has given all notices required of a controller, for collecting its clients'
personal data and for having Rilono process it as described in this DPA — including
processing by the AI sub-processors in Annex II and the international transfers in
Section 7.
- Per-client consent attestation. Rilono requires a staff member to confirm,
when a client record is created, that the client has consented to their personal data being
processed through Rilono. Rilono records the confirmation and the staff member who gave it as
an audit trail. Rilono does not verify that confirmation; it is the
Organization's warranty, and responsibility for its accuracy rests with the Organization.
- Third parties named in files. Client files routinely contain personal data
about people who are not the applicant — sponsors, guarantors, parents, guardians, spouses,
dependants, referees and employers — including their financial evidence. Rilono's AI
extraction records the names of every person appearing in a document. These individuals have
no relationship with Rilono. The Organization is solely responsible for informing
them and for the lawful basis for processing their data.
- Minors. The platform supports destinations whose checklists contemplate
applicants under 18 and their guardians, and Rilono applies no age verification to
client records and holds no age flag on them. Where the Organization enrols a minor,
the Organization is solely responsible for obtaining verifiable parental or guardian consent
and for any additional protections required by Data Protection Laws. The Organization should
note in particular that section 9(3) of the DPDP Act prohibits tracking and
behavioural monitoring of children outright — a prohibition that parental consent does not
cure — and that the portal engagement telemetry described in Section 8 is behavioural data.
Because there is no age flag on a client record, Rilono cannot suppress that telemetry
automatically; the Organization must not issue portal links to clients it knows or believes
to be under 18 unless it has satisfied itself that doing so is lawful.
- Direct contact with clients. Several features have Rilono email the
Organization's clients directly and collect data from them (Section 8). The Organization
instructs Rilono to do so and warrants that it has informed its clients that a third-party
platform will contact them on the Organization's behalf, that messages will be sent from a
rilono.com address branded "{Organization} via Rilono", and that clients may be asked
to upload identity and financial documents directly to Rilono. The Organization is
responsible for providing its clients with its own privacy notice.
- Content the Organization transmits. Staff-authored free text — case notes,
calendar reminder notes and email bodies — is transmitted to clients as written. Rilono acts
only as a conduit and does not review that content.
- Accuracy and rectification. The Organization is responsible for the accuracy
of Client Data, including AI-derived values (extracted fields, validation messages, Deep Scan
risk levels and recommendation rationales) which are generated automatically, may be wrong,
and must be reviewed by the Organization before being relied on. The Organization must
correct inaccurate records through the dashboard.
- Data minimisation. The Organization must not upload data it is not
authorised to share, and should not enter personal data into free-text fields beyond what the
engagement requires.
- Access management. Any active member of the Organization can see every
client record in that Organization. Rilono provides organization-level roles
(administrator, editor, viewer) but no per-record access restriction. Deciding who to invite
and at what role is the Organization's responsibility.
- Data subject requests. The Organization is responsible for responding to its
clients' privacy requests, with Rilono's assistance as described in Section 11.
5. Confidentiality and Security
Rilono keeps Client Data confidential, and personnel with access are bound by confidentiality
obligations and act only on the Organization's instructions or as required by law. Rilono
maintains the technical and organisational measures set out in Annex III.
Client Data is readable by Rilono, by design. The Organization should understand
this before signing. To deliver the AI features in Section 3 — document validation, Deep Scan,
the Copilot, mock interviews and recommendations — Rilono's systems must be able to read the
contents of Client Data. Specifically:
- Uploaded document files are encrypted by the application before they are
written to object storage, using a key Rilono holds, and are decrypted by Rilono's servers
whenever they are read. The storage provider holds ciphertext; Rilono holds the
key.
- The text extracted from documents, the structured facts derived from them,
extracted field values, validation messages, Deep Scan findings, case records, staff notes,
email bodies and interview transcripts are stored in Rilono's database in
readable form, because the AI features must query them.
- Passport numbers on client records are the only category of Client Data for
which Rilono operates field-level encryption at rest. That control is
qualified: it depends on an encryption key being supplied through the
deployment environment, and it is backward-compatible, meaning a value written to the
database before the control was introduced remains in plaintext until that record is next
saved. Rilono has not run a migration to encrypt pre-existing rows. Annex
III(A) and Annex III(H) describe this in full, and the Organization should not treat
passport-number encryption as universal.
No end-to-end encryption for Client Data. Rilono offers end-to-end encryption on
its separate consumer product, where documents are encrypted in the user's browser and the server
holds no key. That feature does not exist in Rilono Enterprise and none of its
protections apply to Client Data. Rilono makes no claim that it is technically unable to
read Client Data, and the Organization should not represent otherwise to its own clients.
Rilono's internal administrative console provides no interface for browsing an Organization's
client records, documents or extracted document text; its Enterprise views are limited to
account, billing and credit metadata. This is an application-layer control, not a cryptographic
one, and it does not restrict access at the database or infrastructure layer by the personnel who
operate the platform.
The Organization is responsible for the security of its own staff accounts and credentials and for
removing access promptly when a staff member leaves.
6. Sub-processors
The Organization gives Rilono general written authorisation to engage sub-processors to process
Client Data. The current register is at Annex II, which names each
sub-processor, what it processes and its processing region. Annex II also identifies, separately
and for transparency only, third parties that process data for which Rilono is a
controller under Section 1 and which is therefore not Client Data.
Rilono imposes data-protection obligations on each sub-processor that are no less protective than
those in this DPA, and remains fully liable to the Organization for a sub-processor's performance
of those obligations.
Change notification and objection. Rilono will give the Organization at least
thirty (30) days' notice before adding or replacing a sub-processor that
processes Client Data, by updating Annex II and notifying the Organization's administrators at
their registered email address. The Organization may object on reasonable data-protection grounds
within fifteen (15) days of that notice. If the parties cannot agree a
resolution, the Organization may terminate the affected Services on written notice without
penalty, with a pro-rata refund of prepaid fees for the unused period. Where a change is required
urgently to protect the security or availability of the Services, Rilono may make it immediately
and notify the Organization without undue delay; the objection right above still applies.
Sub-processor assurance. On the Organization's reasonable written request, Rilono
will pass through any audit report, certification or security documentation it holds in respect
of a sub-processor, to the extent that sub-processor permits disclosure, and will exercise its
own contractual audit and information rights against that sub-processor on the Organization's
behalf where doing so is necessary to address a specific, identified concern.
7. International Transfers
Rilono operates globally and relies on the sub-processors in Annex II, which may store or process
Client Data outside the Organization's own country. Depending on the features the Organization
uses, Client Data may be transferred to and processed in the United States, the European
Union, India, and other regions where those providers operate. AI processing in
particular is performed on Google infrastructure and may take place in the United States.
Rilono maintains data-processing agreements with each sub-processor and transfers Client Data only
as needed for the purposes described in Section 3 and as permitted by Data Protection Laws.
Transfer mechanism — read this before relying on it. Where the Organization is
subject to the EU GDPR or the UK GDPR and requires a transfer mechanism under Chapter V,
the Standard Contractual Clauses are not incorporated into this DPA by reference.
Rilono has deliberately not done so, because clauses incorporated without their options resolved
and their annexes completed are not a reliable safeguard. Instead, Rilono will, on the
Organization's written request and before or at the time the Organization begins transferring
Client Data, enter into the Standard Contractual Clauses with the Organization as a
separate executed schedule to this DPA, completed as follows: Module Two
(controller-to-processor); Clause 7 (docking) included; Clause 9 option (a), general written
authorisation, with the thirty (30) day notice period in Section 6; the Clause 11(a) optional
independent-redress mechanism not included unless the Organization requires it; Clause 17
governed by the law of the EU Member State in which the Organization is established, or Ireland
where the Organization is not established in the EU; and Clause 18(b) forum being the courts of
that Member State. Annex I of this DPA is drafted to complete Annex I of those Clauses, and Annex
III of this DPA to complete their Annex II. For a UK exporter, Rilono will execute the UK
International Data Transfer Addendum with Tables 1 to 4 completed and the Mandatory Clauses
acknowledged.
Until such a schedule is executed between the parties, the Organization should not treat
this DPA on its own as establishing a Chapter V transfer mechanism. Rilono will provide
its transfer impact assessment, and the government-access information described in Section 3, on
written request. Where the Standard Contractual Clauses are executed, their governing-law and
forum provisions prevail over Section 15 for the transfers they govern.
Rilono has not independently verified, and does not represent, the specific storage region of any
individual sub-processor's infrastructure beyond what that provider publishes.
8. Direct Interactions with Data Subjects
Rilono contacts the Organization's clients directly, on the Organization's instruction. This is a
material feature of the Services and the Organization should read this section before using it.
In every case the message is sent from a rilono.com address and is branded
"{Organization} via Rilono". These are transactional messages tied to the client's case;
they carry no marketing content and no unsubscribe link, because clients have no Rilono account.
- Client portal. Staff can issue a read-only portal link. Rilono emails the
link to the client, verifies the client with a one-time code sent to their own email address,
and issues them a short-lived, read-only session. The portal shows the client their own
profile (with the passport number masked to its last three characters), case records,
document list and status, university shortlist and payment history. It has
no write, upload or download capability, and internal free-text counselor
notes and the Organization's commission and payout figures are deliberately withheld. Portal
links expire after 180 days and staff can revoke them at any time, which takes effect
immediately.
- Engagement telemetry. Each time a client opens their portal, Rilono records
the timestamp and increments an open counter, and reports both back to the
Organization's staff as an engagement signal. This is behavioural data about the
client. The Organization instructs Rilono to collect and report it and is responsible for
disclosing it in its own privacy notice. Portal links should not be issued to a
client the Organization knows or believes to be under 18 without the Organization
satisfying itself that doing so is lawful, given the outright prohibition on tracking and
behavioural monitoring of children in section 9(3) of the DPDP Act. Rilono does not currently
offer a per-client or per-share control to suppress telemetry, and holds no age flag on
client records; until it does, the only way to avoid the telemetry is not to issue the link.
Rilono will delete telemetry records for a named client on the Organization's written
request.
- Mock-interview invitations. Rilono emails the client a link allowing them to
take AI mock interviews themselves, verified by one-time code. The full transcript, AI
feedback and verdict are stored on the Organization's account, staff are notified, and Rilono
emails the feedback report to the client. Invitations expire after 30 days.
- Document requests. Rilono emails the client a link, verified by one-time
code, allowing them to upload their own documents directly into the Organization's account.
Client-uploaded documents go through the same AI extraction, validation and
profile-population pipeline as staff uploads. Requests expire after 30 days.
- Calendar reminders. Where staff enable client notification on a case event,
an automated job emails the client the event title, its due status and the staff-written note
verbatim, with no human review at the time of sending.
- Payment requests. See Section 9.
- Outbound email. Staff-composed messages to clients are sent through Rilono
and stored on the client's record, including the message body and any attachments. Where a
document already on file is attached, a separate copy of that document is
created and retained with the sent message, so that the record of what was actually sent
survives later deletion of the original document. Section 13 explains what that means for
deletion and retention.
- Inbound email — dormant, and controlled by Rilono, not by the Organization.
Rilono does not receive clients' replies. Outbound messages carry the sending staff
member's own email address as the Reply-To, so replies go to that staff member's mailbox,
outside Rilono's systems. Rilono has built, but has not activated, the capability to route
replies back into the client record. Activating it would be a platform-wide change
made by Rilono; it is not a setting the Organization holds, and no per-organization control
for it exists. Rilono will not activate it for the Organization's account without
first giving the Organization's administrators written notice under Section 15, and the
Organization may object on the same terms as for a sub-processor change under Section 6. If
it were activated, the reply body, subject and sender address would be stored on the client
record, inbound attachments would not be stored, and the email sub-processor in Annex II
would receive and hold the full inbound message.
Voice mode. Where a mock interview is taken in voice mode, speech synthesis and
speech recognition are performed by the participant's own web browser. Rilono neither receives
nor stores audio — only the resulting text. The Organization should be aware that some browsers
transmit captured audio to their own vendor's speech service; that is a characteristic of the
participant's browser and is outside Rilono's systems and its sub-processor chain.
A capability link alone, before the one-time code is verified, discloses a limited preview: the
Organization's name, the client's first name, destination and visa type, a masked form of their
email address and, for document requests, the list of requested documents and the staff message.
Case data is released only after the one-time code is verified.
9. Payments and Rilono Finance
Rilono Finance lets the Organization collect payments from its own clients through payment links,
using Razorpay Route. Consistent with the Terms & Conditions, the
payment is a transaction between the paying client and the Organization for the Organization's
services; Rilono is not a party to that underlying contract, funds are collected
and settled by Razorpay directly to the Organization's verified bank account, and Rilono never
holds or takes custody of those funds. The two data relationships are different and are set out
separately below.
(a) The client's payment data — Client Data, Rilono as processor. On the
Organization's instruction, Rilono raises a payment request against a client, emails the client a
payment link, hosts the checkout page, and records the outcome. Rilono processes and stores: the
client's name and the email address the link was sent to, invoice number and description, amounts
(including the Organization's commission and payout), due date, payment method (including
off-platform methods such as cash, UPI or cheque recorded by staff), Razorpay order, payment and
transfer identifiers, settlement status and bank UTR, refunds, and dispute status including
chargeback, retrieval, fraud and pre-arbitration phases and reason codes. The client enters their
payment instrument directly with Razorpay; Rilono does not receive or store card or bank
credentials.
Rilono also stores the raw webhook payloads it receives from the payment processor as an
append-only reconciliation ledger. These can contain the payer's contact details and masked
payment-instrument metadata; their retention is governed by Section 13.
(b) The Organization's own onboarding data — not Client Data, Rilono as controller.
To activate collection, the Organization provides business verification and settlement details.
These concern the Organization and its own officers, not its clients, and Rilono does not process
them on the Organization's instruction as a processor. Rilono transmits legal business name,
business type, contact name, email and phone, PAN, GSTIN, stakeholder name and email, and the
full settlement bank account number, IFSC code and beneficiary name to Razorpay for verification.
Rilono does not store the full bank account number — only the last four digits,
the IFSC code and the beneficiary name are retained for display. PAN and GSTIN are stored using
the same field-level encryption control as passport numbers, subject to the same qualifications
set out in Section 5 and Annex III(A). Rilono records the Organization's service-delivery
attestation with its timestamp, version and the IP address from which it was given. Stakeholder
verification material beyond name and email is held by Razorpay, not by Rilono. The
Privacy Policy governs this data.
The Organization remains solely responsible for the accuracy and lawfulness of its payment
requests, for its own tax and invoicing obligations to the payer, for honouring its refund
commitments, and for chargebacks and disputes.
10. Rilono Copilot Browser Extension
Rilono publishes a Chrome extension that gives the Organization's staff access to the Copilot
while they work. The Organization should understand both what it does and what constrains it.
What it can send, and where. Every request the extension makes is routed through
an authenticated rilono.com tab using the staff member's own session, and is checked against a
fixed, hard-coded allowlist of six Rilono endpoints: four read-only endpoints
(the current user, onboarding status, and the Copilot context and client-list endpoints) and two
chat endpoints (general AI chat and Copilot chat). The two chat endpoints are
not read-only — they carry the staff member's prompt and any attached context
outward to Rilono and on to the AI sub-processor, and they
debit the Organization's AI credit meter and write a usage record. They create
and alter no client records. A request to any other endpoint is rejected. The allowlist is
enforced independently in the extension's background worker and again in the page. The extension
declares no external connectivity, so no third-party website can invoke it, and its content
script runs only on rilono.com. The extension cannot send data anywhere other than
Rilono.
What it can read. The allowlist constrains destinations, not content. The
extension includes an "Inspect Page" action which, when a staff member clicks it, reads
the page in the active browser tab and captures the page URL, title and language, up to 28,000
characters of visible text, and up to 220 visible form controls including the values
currently entered in them, together with visible button labels. Password fields are
replaced with a masked placeholder; no other field type is masked. On a government or
institution application form this can include the applicant's identity, contact and history data
as typed. The captured block is attached to the Copilot conversation and transmitted to Rilono
and on to the AI sub-processor. Rilono does not write it to its database —
Copilot conversations and their attachments are held only for the duration of the request. That
says nothing about what the AI sub-processor retains, which is governed by that provider's own
terms.
The controls on that capability. The extension holds no standing access to any
site other than rilono.com. Access to any other site is requested from the browser at the moment
of use, origin by origin, and the browser prompts the staff member to grant it. Capture never
happens in the background or automatically; it requires an explicit click each time.
What the extension is not given. The client list the extension retrieves
deliberately excludes sensitive identifiers such as passport numbers. For completeness, the
Organization should note that the passport number is nevertheless included in the client profile
that Rilono's server assembles and sends to the AI sub-processor for Copilot and Deep
Scan requests, together with the extracted text of the client's documents. Both statements are
true: the extension does not receive the passport number; Rilono's server transmits it to the AI
provider.
The Organization is responsible for instructing its staff on appropriate use of the Inspect Page
action, for the credit consumption those requests cause, and for any third-party terms that
govern the sites on which they use it.
11. Data Subject Requests and Assistance
Clients should direct privacy requests to the Organization in the first instance, because the
Organization — not Rilono — is the controller and Data Fiduciary for Client Data. Where Rilono
receives a request directly from one of the Organization's clients, Rilono will not respond to it
on the merits and will promptly refer it to the Organization, unless legally required to act
otherwise. The Grievance Officer named in Section 16 acts only as a referral point in respect of
Client Data.
Taking into account the nature of the processing, Rilono will provide reasonable assistance to
help the Organization meet its obligations, by appropriate technical and organisational measures
and insofar as possible, including:
- Responding to requests for access, rectification, erasure, restriction, objection and
portability. Most of these the Organization can satisfy itself: client records, case data,
documents, notes, emails, interview results and recommendations are all directly viewable and
editable in the dashboard, and portal, interview and document-request links can be revoked
there. Section 13 sets out the limits of what deletion in the dashboard actually removes, and
what must be requested from Rilono in writing.
- Export. The product does not offer a self-service bulk export. Where the
Organization needs a structured copy of its Client Data, Rilono will produce one through a
manual process within thirty (30) days of a written request from an
administrator, in a commonly used machine-readable format.
- Assisting with the Organization's obligations on security, breach notification, data
protection impact assessments and prior consultation with a supervisory authority, taking
into account the information available to Rilono.
- Providing, on written request, the information in this DPA and its Annexes needed to answer a
client's question about how their data is processed.
Rilono may charge a reasonable fee for assistance that is manifestly unfounded, excessive or
repetitive, having first notified the Organization.
Automated decision-making. Rilono's AI features generate assessments about
individuals — document validation outcomes, Deep Scan risk levels and findings, and
admission-difficulty and rationale text on recommendations. These are decision-support outputs
presented to the Organization's staff; Rilono takes no decision about any client. Where a client
exercises a right in relation to such an output, the Organization is the party that must respond,
and Rilono will assist as set out above.
12. Personal Data Breach
Rilono will notify the Organization without undue delay and in any event within
twenty-four (24) hours after becoming aware of, or forming a reasonable suspicion of, a
personal data breach affecting Client Data. Rilono will not delay an initial notification because
its investigation is incomplete. Notice will be sent to the email addresses of the Organization's
administrators and to any dedicated security contact the Organization has given Rilono in
writing.
The notification will describe, to the extent then known and as further information becomes
available: the nature of the breach and the categories and approximate number of data subjects
and records concerned; the likely consequences; the measures taken or proposed to address it and
mitigate its effects; and a contact point for further information. Rilono will provide updates at
reasonable intervals until the incident is closed, will provide the information reasonably
available to it to help the Organization meet its own notification duties to supervisory
authorities and to affected individuals, and will document the breach and the remedial action
taken.
Notification is not an acknowledgement of fault or liability. Rilono will not notify the
Organization's clients or any supervisory authority about a breach affecting Client Data on the
Organization's behalf unless the Organization instructs it to do so in writing or Rilono is
legally required to.
13. Retention, Return and Deletion
Rilono retains Client Data for as long as the Organization's account is active, except where a
shorter period is stated below. The Organization can delete client records, individual documents,
notes and case data from the dashboard at any time, and doing so is an instruction to Rilono to
delete that data. What that deletion actually reaches today is set out below, and the
Organization should read it before relying on the dashboard as its erasure mechanism.
What dashboard deletion does and does not remove.
- Deleting an individual document from a client's record deletes both the
database record and the encrypted file in object storage.
- Deleting a client record removes that client's database records — the
profile, case data, document metadata, extracted text and structured facts, notes, emails,
interview results and recommendations. It does not currently remove the
corresponding encrypted document files, or the encrypted copies of files attached to messages
already sent, from object storage. Those objects are left in place, unreferenced, as
ciphertext under a key Rilono holds. Rilono will delete them on the Organization's written
request, and is working to make client deletion remove them automatically; until that ships,
an Organization that requires the file objects themselves to be destroyed must ask.
- Sent messages cannot currently be deleted through the dashboard, and neither
can the copy of an attachment stored with a sent message. Rilono will delete a specified sent
message and its stored attachment copy on the Organization's written request.
Retention targets, and how they are enforced. Rilono has adopted the retention
limits below. The Organization should understand that Rilono does not currently operate
an automated retention sweep over Enterprise Client Data; these limits are enforced
operationally, on request and on review, and Rilono is building the automated enforcement. Until
Rilono confirms in an updated version of this DPA that automated enforcement is live, these are
commitments Rilono performs manually, not periods the platform imposes by itself:
- Uploaded client documents — a target of 1,095 days (three years) from upload.
Rilono's objective is to delete the document record, its stored file and the text and
structured facts derived from it no later than 1,095 days after it was uploaded, whether it
was uploaded by staff or by the client. An Organization that needs a shorter or a certain
period should delete documents from the dashboard, which takes effect immediately.
- Raw payment webhook payloads — a target of 180 days. Rilono's objective is
to redact the raw payload received from the payment processor no later than 180 days after
receipt. The ledger record itself is retained — the event identifier, event
type, entity references, amount and timestamps remain, so that payments stay reconcilable
and duplicate events are not reprocessed.
- Copies of documents attached to sent messages are not subject to the 1,095-day
target. They are retained with the message for the life of the client record, or
until Rilono deletes them on written request.
- Capability links. Mock-interview invitations and document requests expire 30
days after issue; portal links expire after 180 days. One-time codes expire after 15 minutes
and lock after six failed attempts. Sessions issued to clients last 3 hours (interviews), 6
hours (document uploads) or 24 hours (portal). These periods are enforced in code.
- Abandoned draft email attachments. Rilono sweeps a staff member's stale
draft attachments, and the files behind them, when that staff member next uploads an
attachment; the sweep targets drafts older than 48 hours. There is no background timer, so a
draft abandoned by a staff member who never composes again can persist until Rilono removes
it, which it will do on written request.
Deletion on termination. On termination or expiry of the Services, and at the
Organization's choice, Rilono will return Client Data (through the manual export process in
Section 11) or delete it. Unless the Organization instructs otherwise in writing within
thirty (30) days of termination, Rilono will delete Client Data within
ninety (90) days of termination, including the object-storage files described
above. Rilono will confirm deletion in writing on request. There is no self-service
organization-closure or tenant-deletion function; termination and deletion are carried out by
Rilono operationally on written instruction.
What deletion does not reach. The Organization should be aware of the following
exceptions, which apply both to deletion of an individual client and to deletion on
termination:
- Object-storage files after client deletion. As described above, deleting a
client record does not itself remove the encrypted document and email-attachment files from
object storage; they remain until deleted on written request or through the
deletion-on-termination process.
- Financial records survive. Payment records are deliberately retained when a
client record is deleted, because they are Rilono's own accounting records. They carry
forward the client's name and the email address the payment link was sent to, de-linked from
the deleted client record. Rilono retains them for the period required by applicable tax and
accounting law, which under Indian law is not less than eight (8) years from
the end of the relevant financial year. This retention is carried out by Rilono as a
controller under Section 1, in reliance on its own legal obligations, is not
used for any other purpose, and is governed by the
Privacy Policy.
- Sent message attachments. A document attached to a message sent to a client
is stored as a separate copy with that message. Deleting the original document does not
delete that copy. Deleting the client record removes the database record of the message and
its attachment but, as noted above, not the underlying stored file.
- Incidental references. A client's name may persist in the Organization's own
credit-usage history (as the label on a charged AI action) and in staff notification records.
Rilono will remove such references on the Organization's written request.
- Legal holds and backups. Rilono may retain Client Data where required by
law, and residual copies may persist in routine backups for a limited period before being
overwritten. Data retained on either basis remains subject to every obligation in this DPA
that survives termination under Section 15, and is not processed for any other purpose.
Where Rilono acts as a controller under Section 1, retention of that data is governed by the
Privacy Policy.
14. Audit
Rilono will make available to the Organization the information necessary to demonstrate compliance
with this DPA and with Article 28 of the GDPR, and will allow for and contribute to audits,
including inspections, conducted by the Organization or an auditor it mandates, on the following
terms.
- Information on request, at any time. Rilono will provide this DPA and its
Annexes, written responses to a reasonable security questionnaire, and any third-party audit
report, certification or penetration-test summary it then holds, on reasonable written
request and without any annual limit. Rilono holds no third-party security
certification at present (see Annex III(H)).
- On-site and hands-on audits. Where the Organization reasonably considers
that the information above is insufficient to address a specific, identified concern, or
where a supervisory authority requires it, the Organization may conduct an on-site or
hands-on audit. Such an audit may be conducted not more than once in any twelve (12)
month period, except where it is required by a supervisory authority or follows a
personal data breach affecting the Organization's Client Data, in which case the frequency
limit does not apply.
- Notice. At least thirty (30) days' prior written notice for
an on-site or hands-on audit, with the scope agreed in advance, save where a supervisory
authority requires shorter notice.
- Sub-processors. Rilono will pass through sub-processor audit reports and
certifications as described in Section 6, and will exercise its own audit and information
rights against a sub-processor on the Organization's reasonable request.
- Conduct. Audits take place during business hours, must not unreasonably
disrupt Rilono's operations, and must not compromise the confidentiality, security or
availability of other customers' data. The Organization's auditor must not be a competitor of
Rilono and must sign a confidentiality undertaking before access is given.
- Confidentiality. All information obtained in an audit is Rilono's
confidential information, may be used only to verify compliance with this DPA, and must not
be disclosed except to the Organization's professional advisers or a supervisory authority
requiring it.
- Cost. Each party bears its own costs. Where an audit requires significant
Rilono personnel time beyond the documentation response, Rilono may charge its reasonable
costs at its then-current professional-services rates, notified and agreed in advance. Where
an audit identifies a material breach of this DPA by Rilono, Rilono bears its own costs and
will remediate at its expense.
15. Term, Liability, Amendments and Order of Precedence
Term. This DPA takes effect when the Organization accepts it and continues for as
long as Rilono processes Client Data. Sections 3, 5, 6, 7, 11, 12, 13, 14, 15 and 16, together
with Annexes I, II and III, survive termination and continue to apply for as long as Rilono
retains any Client Data.
Liability. Each party's liability under or in connection with this DPA is subject
to the exclusions and limitations of liability in the Terms &
Conditions, except as follows:
- The exclusion in the Terms & Conditions of liability for loss of data does
not apply to claims under this DPA or arising out of a personal data breach
affecting Client Data. That exclusion would otherwise remove liability for the very harm this
DPA concerns, and the parties agree it is disapplied here.
- The indemnity given by the Organization in the Terms & Conditions does
not extend to claims arising out of Rilono's own breach of this DPA or of
Data Protection Laws.
- Mutual indemnity. Each party indemnifies the other against claims by data
subjects under Article 82 GDPR (or its equivalent under other Data Protection Laws) and
against administrative fines imposed by a supervisory authority, in each case to the extent
the claim or fine is attributable to that party's own breach of this DPA or of Data
Protection Laws.
- Cap. Subject to the paragraph below, each party's aggregate liability for
all claims under this DPA is limited to the total fees paid or payable by the Organization
for the Services in the twelve (12) months preceding the first event giving rise to the
claim. This cap applies to claims under this DPA in addition to, and separately from, any
general cap in the Terms & Conditions, and is not reduced by claims under those Terms.
Nothing in this DPA or in the Terms & Conditions limits or excludes either party's liability
where it cannot lawfully be limited or excluded, including liability for death or personal injury
caused by negligence, for fraud or fraudulent misrepresentation, and including the rights of data
subjects under Data Protection Laws. Where the Standard Contractual Clauses are executed under
Section 7, nothing in this Section limits the liability provisions of Clause 12 of those Clauses
in respect of the transfers they govern.
Amendments. Rilono may update this DPA to reflect changes to the Services, its
sub-processors or Data Protection Laws. Rilono will publish the updated version, update the "Last
Updated" date and, where a change materially affects the processing of Client Data, notify the
Organization's administrators at their registered email address at least
thirty (30) days before it takes effect. If the Organization objects within that
thirty-day period and the parties cannot agree a resolution, the Organization may terminate the
affected Services without penalty, with a pro-rata refund of prepaid fees for the unused period.
Continued use of the Services after that thirty-day notice period constitutes acceptance of the
updated version. Sub-processor changes follow the notice and objection process in Section 6.
Adding a new purpose or category of processing to Section 3 is a material change requiring notice
under this Section; where it introduces a new category of personal data or a new sub-processor,
it requires the Organization's agreement rather than deemed acceptance. Any change that
materially reduces the protections in this DPA likewise requires the Organization's agreement,
and where the parties disagree on whether a change does so, the Organization may exercise the
objection and termination right above.
Record of the version in force. Rilono records the version of this DPA that an
Organization has accepted, the date of acceptance, and the administrator who accepted it. When
this DPA is updated, the Rilono Enterprise portal notifies the Organization and prompts an
administrator with user-management rights to review and accept the updated version; other staff
are shown the notice but cannot accept on the Organization's behalf. The Organization should
note that Rilono stores only the most recent acceptance — accepting a new
version replaces the previous record rather than adding to a history, so Rilono cannot evidence
the full sequence of versions an Organization has accepted over time. Rilono will supply written
confirmation of the version currently recorded against an Organization on request.
Order of precedence. This DPA supplements the Terms &
Conditions. In the event of any conflict regarding the processing of Client Data, the order
of precedence is: (1) the Standard Contractual Clauses or other transfer mechanism, where
executed and where they apply to the transfer in question; (2) this DPA; (3) the Terms &
Conditions; (4) the Privacy Policy. For all other matters the Terms &
Conditions prevail. For the avoidance of doubt, the Privacy Policy does not override this DPA in
respect of Client Data.
Governing law. This DPA is governed by the laws of India and is subject to the
exclusive jurisdiction of the courts of Bengaluru, Karnataka, India, as provided in the
Terms & Conditions — except that, where the Standard Contractual Clauses
are executed under Section 7, their own governing-law and forum provisions prevail for the
transfers they govern.
16. Contact
Rilono is operated by [REGISTERED ENTITY NAME], a company incorporated in India
(CIN [CIN]) with its registered office at [REGISTERED OFFICE
ADDRESS], Bengaluru, Karnataka, India. These details identify the processor that
contracts under this DPA.
In accordance with India's Digital Personal Data Protection Act, 2023, questions, requests and
complaints about personal data may be addressed to our Grievance Officer.
Scope: the Grievance Officer answers on the merits only in respect of data for
which Rilono is a controller under Section 1. For Client Data, the Organization is the Data
Fiduciary and the Grievance Officer acts as a referral point only, forwarding the request to the
Organization as described in Section 11.
- Grievance Officer: Rilono Data Protection Team
- Email: grievance@rilono.com
We will acknowledge and respond to grievances within the timelines required by applicable law.
EU and UK representatives. Rilono has not at the date of this DPA
appointed a representative under Article 27 of the EU GDPR or of the UK GDPR. An Organization
established in, or with data subjects in, the EU or the UK should take this into account in its
own assessment. Rilono will appoint and publish representatives where it is required to do so,
and will update this Section when it does.
For contractual and commercial matters relating to this DPA, including sub-processor objections,
audit requests, export requests, deletion instructions, requests for the executed Standard
Contractual Clauses, and supervisory-authority correspondence:
Entity: [REGISTERED ENTITY NAME]
Email: contact@rilono.com
Data protection: grievance@rilono.com
Office Region: Bengaluru, Karnataka, India
17. Annex I — Details of Processing
This Annex is drafted so that it can complete Annex I of the Standard Contractual Clauses where
those Clauses are executed under Section 7.
A. Parties
- Data exporter / controller: the Organization, as identified in its Rilono
Enterprise account. Role: controller of Client Data. Contact: the administrator email
addresses registered on the account. Activities relevant to the transfer: providing visa,
education and immigration advisory services to its own clients.
- Data importer / processor: [REGISTERED ENTITY NAME], Bengaluru, Karnataka,
India. Role: processor. Contact: grievance@rilono.com. Activities relevant to the transfer:
operating the Rilono Enterprise platform and carrying out the processing described in
Section 3.
B. Subject matter, duration and frequency
Subject matter. Rilono's provision of the Rilono Enterprise platform to the
Organization, and the processing of Client Data necessary to deliver the features listed in
Section 3.
Duration. For the term of the Organization's subscription, plus the retention and
deletion periods in Section 13.
Frequency of transfer. Continuous, for the duration of the Services. A transfer
occurs each time a staff member or a client uses a feature that involves a sub-processor named in
Annex II.
C. Nature and purpose of the processing
Collection, recording, organisation, structuring, storage, retrieval, adaptation, automated
analysis by AI models, disclosure by transmission to the data subject and to sub-processors,
erasure and destruction — for the purposes enumerated in Section 3, namely: client CRM and
pipeline management; destination-specific case records; document storage; AI text extraction,
document validation, structured field extraction, cross-validation and automated profile
population; whole-dossier Deep Scan audit; AI Copilot in the dashboard and in the browser
extension; AI mock visa interviews, staff-run and client self-serve; outbound email (and inbound
reply capture only if Rilono activates that dormant capability on notice under Section 8); the
read-only client portal and engagement reporting; client document requests; calendar events,
deadlines and automated client reminders; staff notifications; university shortlisting and
Course Finder recommendations; payment collection through Rilono Finance; and platform
operation, security and support.
D. Categories of data subjects
- The Organization's visa applicants (end clients) — the primary category.
They hold no Rilono account; their records are created and controlled by the Organization's
staff.
- Third parties named in a client's documents or derived facts — sponsors,
guarantors, parents, guardians, spouses, dependants, referees, employers and any other person
named in an uploaded document. Rilono's AI extraction records every person name appearing in
a document.
- Minors and their guardians or custodians, where the Organization enrols
applicants under 18. Rilono applies no age verification to client records.
- Third-party payers — a person other than the client who pays a payment
request, and (only if inbound reply capture is ever activated under Section 8) any third
party who replies into a client email thread.
- The Organization's staff users, to the extent their identity appears in
Client Data (for example as the author of a note, the sender of an email or the person who
triggered an AI action). Staff account data itself is processed by Rilono as a controller
under Section 1.
E. Categories of personal data
- Identity and contact data — full name, email address, phone number,
nationality, date of birth. Nationality is not special-category data, but combined with name
and travel documents it may indirectly indicate ethnic origin.
- Government and travel identifiers — passport number (subject to the
qualified field-level encryption described in Section 5 and Annex III(A)) and passport expiry
date.
- Immigration case data — visa category, destination country, visa type,
intake, application reference, pipeline stage, priority, target dates, and structured
per-stage case fields. Depending on destination these include enquiry source and prior
refusal history; funds-evidence status and amounts; tuition deposit; application submission
and visa fee receipts; appointment date, location, reference and biometrics attendance;
case status and information-request dates; visa decision dates, visa document numbers and
validity; passport-return tracking; and refusal date, refusal ground, appeal deadline and
appeal status.
- Destination-specific government identifiers — including SEVIS ID, I-901
receipt, DS-160 confirmation number, consular post and G-221 slip reference (United States);
CAS number, ATAS reference, GWF/UAN number, IHS reference and eVisa share code (United
Kingdom); UCI, IRCC application number, DLI, LOA, PAL/TAL, CAQ and GIC certificate numbers,
biometrics deadline, medical exam status and misrepresentation findings (Canada); TRN, CoE
number, CRICOS code, OSHC policy number, HAP ID, medical clinic date and medical status
(Australia); APS certificate number, blocked-account provider and number, health-insurance
type and VIDEX barcode (Germany); AVATS application number, ILEP programme code and medical
insurance policy number (Ireland).
- Document files and their contents — passports and biometric pages,
photographs, academic transcripts and certificates, admission and offer letters, English-test
results, bank statements and balance certificates, loan sanction letters, sponsor affidavits
with the sponsor's own income and bank evidence, chartered-accountant net-worth statements,
scholarship awards, insurance documents, government forms, prior-refusal documents, and any
other file the Organization or its client uploads.
- AI-derived data — extracted document text; extracted structured fields
(name, date of birth, document number, issue and expiry dates, country and other
information); validation status and free-text validation messages, which are AI judgements
about the person or their evidence; cross-validation conflict flags; cached structured facts
per document, including person names, dates of birth, passport numbers, nationalities,
institutions, financial amounts and key dates; and stored Deep Scan audits comprising a risk
level, summary, findings and checks-passed record, retained as history.
- Communications — outbound email to clients including recipient, subject,
plain-text and rich-text body, attachments and delivery status; and, only if inbound reply
capture is activated under Section 8, the client's reply body, subject and sender
address.
- Interview data — the full transcript of AI mock interviews as authored by
the participant, AI feedback, verdict and mode. Transcripts routinely contain the applicant's
own account of their finances, sponsorship, family circumstances and study intent.
- Recommendation data — university and course shortlists with AI rationale,
competitiveness assessment (reach, match or safety), estimated tuition, requirements and
staff notes; and Course Finder request parameters, AI summary and recommendation lists.
- Payment data — client name and payer email as recorded at the time, invoice
number, description, amounts, commission and payout, due date, payment method including
off-platform methods, payment processor order, payment and transfer identifiers, settlement
status and bank UTR, refunds, and dispute status, phase and reason code (including
fraud-phase disputes, which record an allegation against a named individual). Card and bank
credentials are entered directly with the payment processor and are not received or stored by
Rilono.
- Engagement and technical data — the timestamp and count of each time a
client opens their portal, reported to the Organization's staff; the email address a
capability link was sent to; one-time-code verification attempts; and the IP address of
clients who use the portal, document-upload, interview or payment links, together with the
rate-limit and abuse-prevention counters keyed to it. These client-facing abuse-control
records are Client Data, processed by Rilono as processor on the Organization's instruction
for the security purposes contemplated by Article 32 GDPR; the equivalent records generated
by the Organization's own staff sit in Rilono's controller role under Section 1.
- Staff-authored free text — case notes, hold and refusal notes, rebuttal
plans, calendar event notes and any other free-text field, which may contain any category of
personal data the Organization chooses to enter.
F. Special-category and sensitive data
The Services are not designed to collect special-category data as a distinct field, but it is
routinely and sometimes necessarily present in a student-visa dossier. The
Organization must satisfy itself of a valid condition for processing it under Article 9 GDPR and
the equivalent provisions of the DPDP Act.
- Health data is not incidental. A tuberculosis test certificate is a required
checklist item for the United Kingdom; health or travel insurance proof is required for
Germany and Ireland; and medical examination status is a required case field for Canada and
Australia, including outcomes such as "further tests requested" or "referred to a medical
officer". Health-insurance and eMedical identifiers are recorded as structured fields.
- Immigration-compliance and adverse-history data — prior refusal history
(including overstay, status violation and removal), refusal grounds (including documents
false or unverifiable, character or suitability, and health or security inadmissibility), and
misrepresentation findings including a recorded five-year ban. Under the GDPR this sits close
to Article 10; under the DPDP Act it is sensitive in effect.
- Financial data about both the applicant and third parties — bank balances,
income evidence, loan sanctions, blocked accounts and sponsor affidavits.
- Family and relationship data — dependants included in an application,
marriage and relationship certificates, guardianship and custodianship declarations.
Biometric data — a precise statement. The image of a passport biometric page and
applicant photographs are uploaded and stored. Rilono's processing of them is text and field
extraction only. Rilono performs no facial recognition and creates no biometric
template, and therefore does not process biometric data for the purpose of uniquely
identifying a natural person within the meaning of Article 9 GDPR.
No sensitivity classification. Special-category data is not separately identified,
tagged or segregated in the platform. It resides inside document files, extracted text, derived
facts, case fields, notes, email bodies and interview transcripts, and is handled with the same
controls as all other Client Data.
G. Retention and onward transfers
Retention. Client Data is retained for the periods and on the terms set out in
Section 13, which the Organization should read together with the disclosure there that automated
retention enforcement for Enterprise data is not yet in operation.
Onward transfers. The sub-processors in Annex II(A) process Client Data for the
purposes and for the duration described in Annex II and in Section 3, under data-processing terms
no less protective than this DPA. Rilono does not otherwise transfer Client Data onward, save as
required by law and subject to the government-access commitments in Section 3.
H. Competent supervisory authority
Where the Standard Contractual Clauses are executed under Section 7, the competent supervisory
authority is the authority of the EU Member State in which the Organization is established or,
where the Organization is not established in the EU, the authority of the Member State in which
its Article 27 representative is established or in which the data subjects whose data is
transferred are located. For a UK exporter it is the Information Commissioner's Office. The
parties will record the specific authority in the executed schedule.
I. Roles
For all data described in this Annex I, the Organization is the controller and
Rilono is the processor. The data described in Section 1 as belonging to
Rilono's controller role is not Client Data, is not covered by this Annex, and is governed by the
Privacy Policy.
18. Annex II — Sub-processor Register
A. Sub-processors of Client Data
- Cloudflare, Inc. (Cloudflare R2) — object storage. Stores uploaded client
document files and email-attachment files. Rilono encrypts these files before they are
written, so the provider holds ciphertext. Region: globally distributed object storage.
- Google LLC (Gemini API / Vertex AI) — AI processing. Receives: document
text and files for extraction and validation; for Deep Scan, the client
profile — including name, email, phone, nationality, date of birth and passport
number — together with case records, staff notes, stored emails, university
shortlist, interview results, payment records and document contents; for each
Copilot request, the client profile and document text, including any page
content captured by the browser extension; document-grounded context for
mock interviews; for university shortlisting, the client's
nationality and academic profile (the client's name is not included in that prompt); and for
Course Finder, on every run and regardless of whether search
grounding is used, the client's full name, nationality, destination, visa
type, target intake, target date and up to eighteen scalar case-field values from the
client's case record, alongside the consultant's request parameters and notes. Where PDFs are
processed through the file-upload interface, the file is transmitted to Google's file service
and deletion is then requested. Region: United States and other Google regions.
Terms: Rilono's integration can run through Google Cloud Vertex AI or through
the Gemini API depending on deployment configuration, and the applicable Google terms differ
between them — including on whether Google may use prompts and responses to improve its
services. Rilono does not represent that Client Data is excluded from Google's model
training. An Organization for which this is material should raise it with Rilono in
writing before transferring Client Data.
- Google LLC (Google Search grounding) — a distinct mode of the above, in which
a live Google Search tool call forms part of the model request. This mode is always attempted
for university shortlisting, and is used for Course Finder where Rilono's verified internal
catalogue is thin for the destination. The data sent is as described in the entry above.
Region: as above.
- Resend, Inc. — transactional email. Delivers Rilono's email to the
Organization's staff and, more significantly, directly to the Organization's clients: portal
invitations and one-time codes, interview invitations, codes and feedback reports, document
requests and codes, payment requests, calendar reminders, and staff-composed messages.
Attachment content is transmitted in readable form, so identity and financial documents pass
through this provider. If Rilono ever activates inbound reply capture (Section 8), this
provider would also receive and hold clients' complete inbound messages, including
attachments. Region: United States.
- Razorpay Software Private Limited — payment processing, including Razorpay
Route. Processes the paying client's name, email address and payment instrument, and returns
transaction, settlement, refund and dispute records. Region: India.
B. Third parties processing data for which Rilono is a controller (not Client Data)
Listed for transparency. This data is governed by the Privacy Policy, not
by this DPA.
- Cloudflare, Inc. (Turnstile) — bot mitigation on Enterprise staff
sign-in, sign-up and password reset. Receives the staff member's IP address and a challenge
token. The Turnstile script is loaded by the Enterprise application shell, so Cloudflare sees
the staff member's IP address on Enterprise page loads generally, not only at the
authentication gate. It is not present on the client portal, interview,
document-upload or payment pages and does not process Client Data.
- Razorpay Software Private Limited — verification (KYC) of the Organization's
own business and settlement details under Section 9(b). Region: India.
- Google LLC — federated sign-in for staff accounts that choose it. Rilono
receives email address, verification status, name and a provider subject identifier.
C. Third parties that are not sub-processors
- Reference-data lookups — currency-rate services and published government
maintenance-fund pages. These are requests for reference data only and transmit no personal
data.
- The participant's own web browser — voice mode in mock interviews uses the
browser's built-in speech synthesis and recognition. Rilono receives only text. Any
transmission of audio to a browser vendor's service is a characteristic of that browser, not
a Rilono sub-processing operation.
- Google Cloud Text-to-Speech is used only in Rilono's consumer product and
processes no Client Data.
- Rilono uses no analytics or advertising provider on the Enterprise
dashboard, the client portal or the payment page.
19. Annex III — Technical and Organisational Measures
The measures below are those Rilono actually operates. Rilono has deliberately not listed measures
it does not yet have; Section H below sets those out expressly, and Section 14 describes how the
Organization can verify this Annex.
A. Encryption
- In transit — TLS for all connections, with HTTP Strict Transport Security
applied for one year including subdomains.
- At rest, object storage — uploaded client documents and email attachments
are encrypted by the application, using authenticated symmetric encryption (AES-128 in CBC
mode with HMAC-SHA256 integrity), before being written to storage, and are stored as opaque
binary objects. Keys are held by Rilono and the data is decrypted on read. This is
not end-to-end encryption.
- At rest, field level — with important qualifications. Client passport
numbers, and the Organization's PAN and GSTIN, are configured to be stored under field-level
encryption using the same authenticated cipher. No other Client Data field is individually
encrypted. Three limits apply and the Organization should factor them into its own
assessment: (i) the control depends on an encryption key being present in the deployment
environment — if no key is configured the application logs a warning and stores the value as
plaintext rather than failing; (ii) it is backward-compatible by design, so a value written
before the control was applied to a column is read back as plaintext and stays plaintext
until that record is next saved; and (iii) Rilono has not run a backfill to encrypt
pre-existing rows, so a plaintext tail may remain. Rilono states this rather than
asserting universal coverage.
- Keys are supplied to the application through its deployment environment, and
the field-encryption key may be derived from the application's general secret rather than
from a dedicated, segregated key. Rilono does not currently operate a managed key-management
service, hardware security module or automated key-rotation process, and does not claim
to.
B. Tenant isolation and access control
- Every authenticated request is bound to the caller's organization membership and to that
organization's dedicated portal subdomain; a request whose subdomain does not match the
caller's organization is rejected.
- Record lookups are scoped to the caller's organization. One user account belongs to one
organization.
- Role-based access at the organization level: administrator, editor and viewer. There is no
per-client or per-record restriction within an organization — any active member can see every
client in that organization.
- Rilono's internal administrative console has no interface for reading an organization's
client records, documents or extracted document text; its Enterprise views cover account,
billing and credit metadata only. This is an application-layer control and does not restrict
access at the database or infrastructure layer.
- Rilono personnel are bound by confidentiality obligations and access Client Data only where
needed to operate or support the Services. Rilono does not currently operate
multi-factor authentication or an audit log of personnel access, and does not claim to.
C. Authentication and session security
- Passwords are stored using the bcrypt adaptive hash.
- Session cookies are HttpOnly, Secure and SameSite-restricted, with server-side session
invalidation that revokes previously issued tokens.
- Client-facing capability links (portal, interview, document request, payment) never store the
raw token — only a hash, compared in constant time. Opening a link requires a six-digit
one-time code sent to the client's own email address, valid 15 minutes with a six-attempt
cap. The resulting session is short-lived and scoped to that single purpose.
- Portal payloads mask the passport number to its last three characters and omit internal
counselor free-text notes and the Organization's commission and payout figures.
D. Application and transport hardening
- A Content-Security-Policy restricting script, connect, frame, object, base-uri and
form-action sources to Rilono and a named allowlist of payment, bot-mitigation and analytics
providers. Inline scripts are currently permitted (the policy includes
'unsafe-inline' in script-src), which materially weakens the
containment a Content-Security-Policy would otherwise give against cross-site scripting.
Rilono states this rather than describing the policy as strict. The header is emitted by
default and its value is configurable through the deployment environment.
- frame-ancestors and X-Frame-Options set to deny, X-Content-Type-Options nosniff, a strict
referrer policy, and cross-origin opener and resource policies.
- An explicit cross-origin allowlist with no wildcard origin.
- All API responses are marked private and no-store and vary on credentials.
- Uploaded files are checked against an extension allowlist and a size cap, stored under
non-guessable keys, and served only through authenticated, organization-scoped endpoints —
never from a public or pre-signed URL. The served content type is derived from the validated
extension rather than from the uploader's declared type, and anything not known-safe is
forced to download, which substantially reduces the risk of stored cross-site scripting from
uploaded files. Rich-text email bodies are sanitised before sending.
- Rilono relies on SameSite cookie enforcement rather than synchroniser-token CSRF protection,
and states this expressly rather than claiming a control it does not have.
E. Abuse prevention and integrity
- Rate limiting on authentication, administrative, AI, upload, email and all public
client-facing endpoints, keyed to the requesting IP address and, where relevant, the
organization or user.
- Bot mitigation on staff sign-in, sign-up and password reset.
- Inbound webhooks from the payment processor and the email provider are verified by
HMAC-SHA256 signature over the raw request body, compared in constant time. A request-size
cap is applied to the inbound-email webhook; the payment webhook is rate-limited but is
not currently size-capped.
- Webhook events are de-duplicated against a unique event identifier so that a repeated event
is not reprocessed. This engages where the provider supplies its event-identifier header; a
signed event delivered without one is not currently caught by that constraint.
F. AI processing controls
- Copilot conversations and any context attached to them, including page content captured by
the browser extension, are processed for the duration of the request and are
not written to Rilono's database. What the AI sub-processor retains is
governed by that provider's terms, not by this control.
- The browser extension can transmit only to a fixed allowlist of six Rilono endpoints — four
read-only, and two chat endpoints that carry the prompt and any attached context outward and
debit the Organization's credit meter — always through an authenticated rilono.com tab, and
it can be invoked by no third-party site. Page capture requires an explicit per-origin
browser permission granted at the moment of use, and password fields are masked.
- The client list exposed to the browser extension deliberately excludes passport numbers.
- On the client-facing mock-interview path, staff notes are excluded from the model prompt.
- AI usage is metered per organization and per user for billing and cost control; those
metering records store token counts, model and cost, not prompt or response content.
G. Operational resilience and assurance
- Availability and backups. The platform's database and object storage run on
managed cloud infrastructure with the provider's own redundancy and routine backups. Rilono
does not currently publish a recovery time or recovery point objective and does not commit to
one in this DPA.
- Vulnerability and dependency management. Rilono applies security updates to
its application dependencies and hosting platform on an ongoing basis. Rilono does not
currently commit to a defined patching cadence.
- Incident handling. Rilono investigates suspected security incidents on
becoming aware of them and notifies the Organization on the terms in Section 12.
- Personnel. Rilono personnel are bound by written confidentiality
obligations.
H. Measures Rilono does not currently claim
For the avoidance of doubt, and so that the Organization's own assessment is accurate, Rilono does
not presently claim any of the following. Rilono will update this Annex as these change, in line
with Section 15.
- End-to-end or zero-knowledge encryption of Client Data.
- A managed key-management service, hardware security module, key rotation, or a field
encryption key segregated from the application's general secret.
- A completed backfill of field-level encryption over rows written before that control was
applied.
- Multi-factor authentication for staff accounts, or audit logging of Rilono personnel access
to Client Data.
- Synchroniser-token CSRF protection, or a Content-Security-Policy that excludes inline
scripts.
- Per-record access control within an organization.
- Automated retention enforcement for Enterprise Client Data, or an automated
tenant-offboarding or organization-deletion routine — the retention and deletion commitments
in Section 13 are performed operationally.
- Automatic removal of object-storage files when a client record is deleted
(see Section 13).
- A request-size cap on the payment-processor webhook, or de-duplication of signed webhook
events delivered without the provider's event-identifier header.
- A per-organization control over inbound email reply capture (see Section 8), or a per-client
control over portal engagement telemetry (see Section 8).
- A periodic penetration test, a formal programme for regularly testing and evaluating the
effectiveness of these measures under Article 32(1)(d) GDPR, a documented disaster-recovery
plan with tested restores, formal personnel background screening or a recurring security
training programme, or any third-party security certification or attestation (such as
ISO/IEC 27001 or SOC 2).
