Data Processing Agreement

What this agreement covers

When you engage Dreams Event to run an event and you give us information about the people taking part, you are deciding what data goes in and what happens to it, and we are running the event that uses it. Data protection law treats those two roles differently, and this agreement sets out the difference in plain terms.

It covers personal data about your participants, your staff and your contacts that we process in order to plan and deliver your event.

It does not cover the details you send us through our website when you enquire, or the booking and billing information we hold about you in our own right — our Privacy Policy covers that, and in that context we act for ourselves and not as your processor.

Who is what

You are the controller — the Data Fiduciary, in the language of India's Digital Personal Data Protection Act, 2023. You decide why the data is processed and on what basis you are entitled to hold it. If you are a processor for someone else in turn, you confirm you have the authority to give us the instructions this agreement contemplates.

We are the processor — the Data Processor. We act on your documented instructions, we do not decide the purposes of processing, and we do not treat your participant data as ours to use.

We are also a separate controller for a narrow set of things: your booking, your invoices, support conversations and the security of our own systems. Where we act for ourselves, our Privacy Policy applies and this agreement does not.

Terms used in this agreement

These definitions are deliberately short. Where a term is defined in an applicable data protection law, that definition applies instead.

• Client means the organisation that engages Dreams Event — you.
• Personal data means information about an identifiable person that we process for you.
• Processing means anything done with that data: storing it, organising it, sharing it, reading it, sending it, deleting it.
• Data subject — or Data Principal — means the person the data is about, usually a participant or a contact.
• Sub-processor means another company we engage to process data on your behalf.
• Security incident means a confirmed breach of security leading to accidental or unlawful loss, alteration, disclosure or access to personal data we process for you.
• Applicable data protection law means the law that applies to the processing in question, which for most of our clients is India's Digital Personal Data Protection Act, 2023 and the rules made under it, plus any law of another country that reaches the data.

What we process, and why

We process the data you or your participants give us in order to plan, run and follow up on your event — nothing more. In practice that means participant names, ages, contact numbers, emergency contacts, medical or dietary requirements where you pass them to us, supervision and consent records, and the coordination details we need on the day.

We process it for these purposes and no others: to plan and deliver the event safely; to coordinate with venues, suppliers and our own staff; to handle an incident or an emergency; and to meet our own legal, tax and accounting obligations.

We do not sell it. We do not use your participants' data to market to them, or to anyone else. We do not use it to build audiences or to train models for our own product development.

Our obligations as your processor

• Process personal data only on your documented instructions, including the instructions in this agreement and in the plan you have confirmed with us.
• Tell you promptly if an instruction would, in our reasonable opinion, breach applicable data protection law — and not carry it out until you confirm it.
• Keep the data confidential, and bind everyone who has access to it to confidentiality.
• Implement the security measures set out in this agreement.
• Help you answer requests from participants and their guardians about their data, as described further down.
• Help you with your own obligations, including any data protection impact assessment or consultation with a regulator, by giving you the information you reasonably need.
• Delete or return the data when the engagement ends, as described further down.
• Let you audit our compliance, within the limits set out further down.

Your obligations as controller

We depend on you getting these right. If data is processed that should not have been, or an image is published that should not have been, the consequences land on you and on the people concerned, not only on us.

• Make sure you have a lawful basis for the data you give us, and give participants — and, where they are children, their parents or guardians — a privacy notice that covers the fact that you have engaged a company like ours.
• Obtain and record any consent that applies before you pass the data to us, in particular for children, for medical information, and for photographs and video.
• Only give us data you are entitled to give us, for purposes you are entitled to pursue.
• Keep your own records of the consent you obtained, so that you can show it if you are asked.
• Tell us promptly if a participant withdraws consent or objects to being photographed, so that we can act on it.
• Give us instructions that are lawful, and tell us if something you have asked for becomes unlawful.
• Keep your own account credentials and coordination details secure, and tell us promptly if you think someone else has access to them.

If we disagree with an instruction

If you instruct us to do something we believe breaches data protection law, we will tell you why and ask you to confirm before we act. If you confirm and we still believe it is unlawful, we may decline. We will not simply execute an instruction we know to be unlawful because an agreement says we must.

Sub-processors

You authorise us to engage sub-processors, and you accept the categories of sub-processor set out below. That is a general authorisation rather than a case-by-case one, because we cannot run an event otherwise.

When we engage a sub-processor, we put a written agreement in place that imposes obligations on it that are no less protective than the ones in this agreement — including confidentiality, security, deletion and assistance with data-subject requests. We remain responsible to you for what a sub-processor does, and for what it fails to do.

We tell you before a new sub-processor in a new category begins processing your data. If you object on reasonable data-protection grounds, we will look for a way to deliver the event without that sub-processor, or let you end the affected part of the engagement without penalty.

One item on that list is not substitutable, and we would rather say so plainly. If you have agreed to receive updates over WhatsApp, message delivery runs through Meta, and there is no way to deliver WhatsApp messages without it. Meta's own WhatsApp Business Data Processing Terms apply to its processing.

How we secure the data

These are the measures we maintain. They are stated as facts about the way we work, not as aspirations, because this is the section a security reviewer will test against our actual practice.

• Encryption in transit: connections to our systems and to our service providers use TLS 1.2 or higher. Plain HTTP is not accepted.
• Encryption at rest: databases, storage and backups are encrypted using managed keys.
• Access control: access to participant data is limited by role, granted on a least-privilege basis, and reviewed periodically.
• Separation between clients: each client's event data is kept apart, so one client cannot reach another's records.
• Multi-factor authentication: required for administrative and remote access to systems that can reach your data.
• Account lifecycle: access is granted, changed and revoked through a defined process, including promptly when someone leaves.
• Credential handling: keys, tokens and secrets are stored in a secret manager, never in source control, and rotated when there is reason to.
• Secure development: dependencies are kept patched, and changes are reviewed before release.
• Monitoring and logging: access to production systems is logged, and we watch for anomalous access.
• Vulnerability management: we review our systems for security weaknesses at least once every twelve months and address findings by severity.
• Incident response: we maintain and periodically test a written incident response plan.
• Secure disposal: data is deleted using methods that make it unrecoverable in the ordinary course.

If something goes wrong

If we become aware of a security incident affecting your data, we will tell you without undue delay, and in any event within seventy-two hours of becoming aware. We will tell you what we know at that point, even where our investigation is still running, rather than wait for a complete picture.

Our notice will describe what happened, the data and people affected as far as we can tell, what we are doing about it, and what we recommend you do. We will keep you updated as the investigation progresses, and we will not leave you to chase us for the next update.

We will not describe an incident in a way designed to minimise it, and we will not tell you a breach cannot have affected you without a basis for saying so. We will also not notify your participants on your behalf — that is your call to make, and we will give you what you need to make it.

We record incidents and the action we took, and will give you that record on request.

When your participants ask about their data

People will approach you to access, correct, export or delete their data. It is your responsibility to respond to them, because you are the controller and you know who they are.

If someone contacts us directly, we will point them to you rather than answering ourselves, unless the law obliges us to respond. We will tell you when this happens.

When you need to answer a request, tell us and we will help: we will retrieve, correct, export or delete what you identify, and give you the information about our processing that you need. We will do this within a period that lets you meet your own deadline, and we will not charge for reasonable requests.

Deleting the data

We delete personal data we process for you when you ask us to, when it is no longer needed for the purpose you gave it to us for, when the engagement ends, or when the law requires it. In each case we do it as soon as reasonably possible, and in any event within one hundred and twenty days unless a legal requirement obliges us to keep it longer.

When we delete, we remove the data from live systems and, in the ordinary course, from backups, and we tell you it is done. Where deletion is genuinely impossible — an immutable backup rotation already under way, for example — we keep the data isolated and stop processing it for anything other than storage until deletion completes.

Two limits are worth knowing about. We may keep records that the law requires us to keep, such as invoices and tax records, and we may keep de-identified or aggregated information that can no longer be linked to a person. Neither is personal data once the link is gone.

If message data is involved, we do not control all of it. Where you have agreed to receive updates over WhatsApp, Meta retains message data for a maximum of thirty days for delivery and retransmission, and we cannot shorten that period by contract.

Sending data outside India

Some sub-processors process data outside India. Where data leaves India, we rely on the transfer mechanisms available under applicable law, and we will tell you where each provider we use processes data.

We do not choose a provider on the basis of a lower standard of protection, and we do not move your data to a jurisdiction to escape an obligation. If you need a specific processing location or a specific transfer mechanism before you can engage us, raise it before you book — some of it we can accommodate, and we would rather say so then than discover it later.

Auditing us

You may audit our compliance with this agreement once in any twelve-month period, on at least thirty days' written notice, during business hours, and at your own cost. Audits must be conducted in a way that does not compromise the security of other clients' data.

We would rather satisfy you with evidence than with an inspection. We will give you our security documentation, our sub-processor agreements on a confidential basis, our incident records, and any current third-party certification we hold. Where a certification from a recognised auditor is current and covers the systems in question, we may offer that instead of an on-site audit, and you agree that it satisfies this clause.

An audit that arises from a security incident affecting your data, or from a regulator's requirement, is not counted against the once-a-year limit.

Our liability to each other

This agreement does not increase the liability either of us has under our Terms of Service, and the limits and exclusions in those terms apply to claims arising out of this agreement as they do to the rest of our services.

Where we are found liable for something a sub-processor did, we are responsible to you for it. Where you are found liable because of an instruction you gave us, or because you passed us data you were not entitled to hold, you remain responsible for that.

Term, and what survives the end

This agreement runs as long as we process data for you, and ends when the last of it is deleted or returned. That is usually shortly after your event and the work around it are complete, but the deletion section above governs the timing rather than the event date.

The obligations about confidentiality, deletion and liability survive the end of the agreement for as long as they are needed to give them effect.

Governing law, and which document wins

This agreement is governed by the laws of India, and disputes are subject to the exclusive jurisdiction of the courts at Kottayam, Kerala. That matches our Terms of Service deliberately — an agreement that sent the two documents to different courts would create more disputes than it resolved.

If this agreement and the Terms of Service disagree about the processing of personal data, this agreement wins. If this agreement and a signed order form or proposal disagree, the signed document wins, but only where it expressly says it is amending this agreement.

If we make a material change to this agreement, we will update the date at the top of the page and give notice to clients holding a written agreement, for the period set out in it.

Data protection contact

Questions about this agreement, requests to sign a copy, notices about a security incident, and objections to a new sub-processor all go to info@dreamsevent.co.in. Our grievance officer reads this mailbox and will route your message to the person who can answer it.

[legal entity name]
[registered office address]
Keezhampara Melampara P O
Pala Erattupetta Road
Pala, Kottayam – 686578
Kerala, India