1. When this addendum applies
This addendum applies only where both of these are true: you are a financial entity in scope of Regulation (EU) 2022/2554 (the Digital Operational Resilience Act, "DORA"), and you hold an Order with us that names this addendum. It does not apply to a self-serve Workspace, it does not apply because you happen to be a bank or an insurer, and it is not incorporated into our Terms of Service by default. To put it in place, email [email protected] before you sign.
Where this addendum applies it supplements our Terms of Service, our Enterprise Terms at /enterprise-terms and our DPA at /dpa. Where it conflicts with those, this addendum wins for the ICT services it covers; where it conflicts with a signed Order, the Order wins.
Vibely is operated by Mana Intelligence Private Limited, incorporated in India. We are an ICT third-party service provider for the purposes of DORA. We are not a designated critical ICT third-party service provider, we have not been notified of any such designation, and we are not established in the European Union.
2. Why this page is written the way it is
Article 30 lists provisions that have to be in your contract with an ICT provider. Some of them we can hold. Some of them we cannot hold today, and an addendum that promised them anyway would fail you at exactly the moment you relied on it — in an incident, or in front of your supervisor. Each section below says which it is. Where the answer is no, the section says no, and says what we will do instead. If a gap is a blocker for your procurement, you need to know that before the Order rather than after.
3. Description of the ICT services — Article 30(2)(a)
Vibely is a hosted service that generates, builds, previews and deploys software from natural-language prompts. Concretely we provide: a web application for authoring Projects; AI inference through third-party model providers; ephemeral build and preview sandboxes; a database, authentication and file storage layer for your Projects; hosting for Published Apps on a vibelyagent.com subdomain or a custom domain you connect; and a mobile build pipeline that produces binaries you ship under your own Apple and Google developer accounts.
What we do not provide: we do not process payments for you, we do not hold client money, we do not operate a trading, ledger, clearing, settlement, reporting or record-keeping system, and we do not act as an outsourced operator of any function you run. We are a development and hosting tool.
Sub-contracting. We use sub-contractors for every layer above — cloud hosting, sandboxes, model inference, payments, email, observability, the connector gateway and the mobile build pipeline. Each one, what it does and where it processes, is listed at /subprocessors, and we post a change there before the new sub-processor begins processing. We will not agree to a sub-contracting consent right that requires our written notice to you and your approval before each change; the published list plus your objection right under /dpa is what we operate.
4. Whether the services support a critical or important function — Article 30(2)(a)
By default, no. We contract on the basis that Vibely does not support a critical or important function of your business, and our service levels, our staffing and this addendum are built for that.
Only you can classify the function, not us. If you intend to use Vibely to support a critical or important function, say so in the Order and describe the function. We will tell you in writing, before signature, whether we can support that use — and for most of the Article 30(3) package the honest answer today is that we cannot. Specifically: we cannot offer unrestricted on-site inspection, we cannot take part in threat-led penetration testing of infrastructure we do not own, and we do not run a dedicated exit or transition team. Those are the sections below that say so.
If you classify the function as critical or important and sign anyway without an Order term addressing those gaps, you are carrying the difference. We would rather lose the deal than have you discover that in a supervisory review.
5. Locations of service provision and data processing — Article 30(2)(b)
Application servers and the sandboxes your Projects build and run in are in the United States (AWS us-east-1). The primary database, authentication and file storage run on Supabase in Singapore (ap-southeast-1). Our CDN serves from edge locations worldwide. Our team performs the services from India.
We do not operate an EU or an India hosting region today and we are not naming a date for one. There is no region selector. If EU-only processing is a hard requirement for you, we are not a fit and you should stop here.
Data at rest is stored in the Singapore database and the associated object storage, plus encrypted backups held by those providers. Model inference is performed by the providers listed at /subprocessors, in the regions stated there; two of them process in China and we hold no European Commission Standard Contractual Clauses with either, which is stated plainly at /privacy-policy.
Change of location. We will give you at least 30 days’ written notice before we move the storage location of your data or the region your Projects are served from, to the email address on the Order. If the new location is not acceptable to you, you may terminate for convenience within that notice period with a pro-rata refund of prepaid fees for the unused term.
6. Availability, authenticity, integrity and confidentiality — Article 30(2)(c)
Availability. Our commitment is a Monthly Uptime Percentage of 99.5%, measured and credited as set out at /sla. That is 3 hours and 39 minutes of downtime in a 30-day month before a credit is due. We publish that number because it is the one we can hold on the infrastructure we run, not because it is the one that reads best. If your operational risk framework requires a higher figure, ask before the Order and we will either write it or tell you we cannot.
Integrity and authenticity. Data in transit is encrypted with TLS. Data at rest is encrypted by our storage providers. Changes to your Projects are versioned and attributable to the account that made them, and administrative actions in our own systems are logged. We do not offer cryptographic signing or tamper-evident logging of your application data, and we do not hold a WORM or immutable-storage option.
Confidentiality, including personal data. The processing terms, the security measures, the SCC position and the breach-notification obligation are in our DPA at /dpa, including notification to you without undue delay and within 72 hours of us becoming aware of a personal data breach. Our current security posture is at /security. We hold no SOC 2 report and no ISO 27001 certificate, no audit against either is under way, and we are not naming a date for one.
7. Service levels and reporting — Article 30(2)(e) and 30(3)(a)
The service level description, the measurement method, the exclusions, the credit thresholds and the claim window are at /sla. It is a single quantitative target — monthly uptime — not a full matrix of performance indicators. We do not currently commit to response-time percentiles, build-success rates, or inference latency, and we will not sign an Order that states them until we measure them.
Reporting. On an Order that names this addendum we will send you a written monthly service report covering measured uptime against the commitment, any incident that affected your Workspace with its duration and cause, and any change of sub-processor or data location in the period. We will send it within 10 business days of month end. That report is the reporting obligation under Article 30(3)(a) as we can actually meet it — a named human writing it, not a dashboard.
Material changes to the SLA come with at least 14 days’ notice, and an Order that states an uptime commitment overrides the published one for its term.
8. Assistance on an ICT incident — Article 30(2)(f)
Where an ICT-related incident affects the services we provide to you, we will assist you at no additional cost. That assistance is: telling you what happened and when, by email to the contact on the Order; giving you the timeline, the scope of affected data or Projects, and what we did; providing the log extracts and evidence we hold that relate to your Workspace; and answering follow-up questions in writing while your own report to your competent authority is being prepared.
Say the awkward part. We do not staff a 24/7 on-call rota and we do not offer a contractual response time measured in minutes. We monitor our contact addresses on Indian business days. For an incident we detect ourselves, the response starts when we detect it, at any hour. For an incident you report, assume a first substantive response on the next Indian business day unless the Order says otherwise. If you need a 24/7 committed response to meet your own DORA incident-reporting deadlines, we cannot give it and you should not rely on us for it.
Where an incident relates to a service one of our sub-processors provides, we will pass on what they tell us. We cannot commit to timelines we do not control and we will not restate a sub-processor’s commitment as our own.
We also have our own incident duties as an Indian entity, including CERT-In reporting for specified cyber incidents, and nothing here limits them.
9. Cooperation with competent and resolution authorities — Article 30(2)(g)
We will cooperate fully with your competent authorities, including a resolution authority, and with anyone they appoint. That means giving them access to the information they request about the services we provide to you, answering their questions in writing, and not obstructing their exercise of powers in relation to your use of Vibely.
Practical limits you should know. We have no establishment in the European Union, no EU representative, and no separate mailbox for authorities. Correspondence reaches us in English at [email protected] and is read on Indian business days. We are not subject to direct EU supervisory oversight and we are not making ourselves subject to it by signing this addendum; our cooperation is contractual.
If an authority requires attendance at a meeting, we will attend remotely. If an authority requires a physical presence in the European Union, we cannot provide one.
10. Access, inspection and audit rights — Article 30(3)(e)
You, an auditor you appoint, and your competent authority have the right to access, inspect and audit our provision of the services to you. What that looks like in practice:
- Documentation, on request and without a fee: our security documentation at /security, the sub-processor schedule, the DPA and its annexes, our incident history for your Workspace, and written answers to a security questionnaire once per 12 months.
- A remote audit once per 12 months on 30 days’ written notice, in business hours, conducted by you or an auditor bound by confidentiality who is not a competitor of ours. More frequently if a material incident affects you, or if your competent authority requires it.
- An audit by your competent authority, or by someone it appoints, on the notice the authority requires rather than the notice above. We will not use the notice period or the frequency cap against a regulator.
- What we do not offer: unannounced access, continuous or automated audit access to our systems, penetration testing of our production environment outside /responsible-disclosure, or access to the systems and premises of our sub-processors, which we do not control and cannot grant on their behalf.
- On-site inspection at our premises in India: we will not refuse your competent authority, on the notice the authority requires. For a customer or a customer-appointed auditor it is not a standing right under this addendum — we are a small company and an on-site week costs more than most contracts are worth. Ask for it in the Order and we will either agree it in writing, with the notice and cost terms stated there, or tell you before signature that we cannot. We will not write a right into this page that we would argue about when you tried to use it.
11. Threat-led penetration testing
Article 30(3) contemplates participation in TLPT for services supporting a critical or important function. We cannot take part in a TLPT exercise against infrastructure we do not own — AWS, Supabase, our CDN and our model providers each have their own testing policies, and we cannot authorise testing of them. For our own surfaces, testing is welcome under the scope and rules of engagement at /responsible-disclosure, and our contact is published at /.well-known/security.txt. If your TLPT programme requires our participation as a contractual obligation, tell us in the Order and we will say in writing what we can join and what we cannot.
12. Access, recovery and return of data — Article 30(2)(d)
Your Projects, the code we generate for you, and your Project data are yours. Source code exports from the product at any time as a zip in ordinary repository layout, or pushes to a GitHub repository you own; that works while your account is open and does not depend on us being available to help. Database contents and stored files live in the Supabase project connected to your Workspace, under your own Supabase account, and export through that provider’s own tools rather than ours. We do not today ship a one-click export of the whole Workspace, and we are not naming a date for one.
On termination, insolvency, resolution or discontinuation of the service, you keep that export right for 30 days after the end of the term, and we will not disable export before deletion. The retention and purge windows are the real ones: a Project you delete is torn down and its storage purged in the same operation, with no grace period and no undo; personal data is deleted within 30 days of account closure, except where law requires us to keep it. Copies may persist in encrypted backups for a limited period after the purge and are not restored into the live service.
If we discontinue the service as a whole, we will give at least 90 days’ notice to the contact on the Order, keep export working for the whole of that period, and refund the prepaid fees for the unused remainder of the term.
13. Exit strategy and transition period — Article 30(3)(f)
Here is the honest position. We do not have a dedicated exit-support team, a named transition manager, or a migration engineering function, and we are not going to write one into a contract to win a deal. What makes exit from Vibely workable is that there is not much to exit from: the code is ordinary application code you already hold, and it runs anywhere that runs it.
What we do commit to on exit:
- A transition period of up to 90 days after termination or expiry, on request, during which the service continues on the same terms at the same price, so you are never choosing between migrating and running. Longer if the Order says so.
- Source-code export for every Project throughout that period, plus one export assisted by us — meaning we run it, check it and hand you the archive — at no additional cost. Where database contents or stored files sit in a Supabase project we provisioned rather than one you own, that export is included in the assisted export.
- Continued DNS and hosting for a Published App on a custom domain during the transition period, and help pointing that domain elsewhere.
- Mobile apps are already outside the dependency: binaries are built for and submitted under your own Apple and Google developer accounts, so a Vibely exit does not affect your store listings.
- A written statement, on request, of what we hold, where, and when it will be deleted — the artefact your own exit plan needs as evidence.
- What we do not commit to: re-platforming your application, standing up your new environment, writing migration scripts for your target stack, or providing staff seconded to your transition. If you need that, contract it separately and price it.
14. Termination rights — Article 28(7)
You may terminate the Order, without penalty and without a termination fee, on written notice in any of these circumstances:
- A significant breach by us of applicable law, regulation or the contract terms.
- Circumstances identified through your own monitoring of ICT third-party risk that are capable of altering the performance of the functions we provide, including a material change to our sub-processors, our data locations or our ownership.
- Evidenced weaknesses in our overall ICT risk management, in particular in how we secure the availability, authenticity, integrity or confidentiality of data.
- Where your competent authority can no longer effectively supervise you as a result of the contract or of how we perform it.
- Separately, where we fall below 99.0% uptime on the same commitment in three consecutive months, as set out at /sla.
15. Notice periods and continuity on termination
Termination by us for convenience requires at least 90 days’ written notice on an Order that names this addendum. We may still suspend or terminate immediately for non-payment, for fraud, or for a material breach of our Acceptable Use Policy at /acceptable-use — and in those cases the transition period above does not apply, although the 30-day export window does. Termination for any reason does not shorten the export and deletion windows in the section above.
16. Security awareness and training programmes — Article 30(2)(i)
We do not run a formal security awareness or digital operational resilience training programme that your staff could join, and we will not claim one. What we will do, where your Order requires it: take part in your own awareness or resilience training at a reasonable cadence, provide our people for a briefing on how the service works and where its limits are, and give you our security documentation for use in your own materials. If you need evidence of internal training on our side, ask before the Order and we will tell you exactly what we can evidence.
17. Your register of information — Article 28(3)
You have to maintain a register of information on all contractual arrangements with ICT third-party providers, and report it to your competent authority. We will give you what we hold for it, on request: our legal name (Mana Intelligence Private Limited), our Indian Corporate Identity Number, our country of incorporation and head office, the services covered, the data locations above, the sub-processor list, and the function classification you have given the arrangement.
We do not hold a Legal Entity Identifier (LEI) or an EUID today. If your register submission requires an LEI for the provider, tell us early — obtaining one takes weeks, not days, and we would rather start before your reporting deadline than after it.
18. Changes to this addendum
Where this addendum is named in an Order, the version in force is the one published on the day that Order was signed, and we will not change it for you mid-term without your written agreement. We will give at least 30 days’ notice by email before a change takes effect for a renewal.
19. How to raise this with us
For an Order, a security questionnaire, or a specific Article 30 provision you need written differently, email [email protected]. For anything about data protection, sub-processors or an incident, email [email protected]. The other legal documents this addendum sits on top of are listed under “Documents that form part of these Terms” in the Terms of Service at /terms-of-service.