Data Processing Agreement — Item Approval Workflow

Last updated: 6 September 2026

This Data Processing Agreement ("DPA") governs the processing of personal data by the Item Approval Workflow app for monday.com ("the app"), supplied by Kauê Natan Gonçalves Bidim, trading as Saoirse Software, in Ireland ("we", "us", "the Processor"). It forms part of the Terms of Service and should be read with the Privacy Policy.

How this DPA is entered into. This DPA applies automatically between us and your organisation from the moment the app is installed on your monday.com account, for as long as it remains installed. No signature is required for it to be binding. If your legal team needs a countersigned copy, or needs it attached to your own paper, email help@saoirsesoftware.com and we will sign and return it.

1. Roles

Your organisation — the monday.com customer that installed the app — is the data controller. It decides which boards the app is used on, who signs off, which columns count as a change, and what an approval means in your processes. We are the data processor: we process data only to make the app work, and only on your instructions.

Your instructions are given through the app itself and through this DPA. We will not process data from your monday.com account for any other purpose — not for our own analytics, not for product research, not for marketing, and not for training any machine-learning or AI model. We do not sell personal data and receive no payment from anyone for access to it.

2. What is processed

The app keeps one record per board, plus a small index and a subscription record per account. The table below is the whole of what those records contain.

Subject matter	Recording who signed off which version of a monday.com item, the decisions taken, and whether the item has changed since.
Duration	For as long as the app is installed on your monday.com account.
Nature and purpose	Storing and displaying approval requests and decisions; deriving a version number for an item from the columns being watched; showing what changed since an approval; listing what is waiting for a person; producing a board report; and answering the six assistant actions described below.
Categories of data subject	People who hold a user account on your monday.com account and who open the app, send an item for approval, or take a decision on one. Also, indirectly, any person named inside a column that the app is watching (see "board content" below).
Written down (1) — approvals and decisions	Per item, in the record of the board it belongs to: the item ID and the board it belongs to; who was asked to sign off, as monday.com user IDs; who signed off, on which version number, and when; the decision — approved, or changes requested; the free-text reason where an item was sent back, which the app requires.
Written down (2) — board content, stated plainly	A monday.com item has no version number of its own, so the app derives one. It stores, per item: the item name, a version number, a date, and — for each watched, non-empty column — the column's title, a preview of its value cut off at 512 characters, and a short numeric summary of the whole value used only for comparison. This is content from your boards, and if a watched column holds personal data (a People column, or free text somebody typed a name into) that value is inside the snapshot. It exists because naming the column that changed since an approval is not possible from a number alone. Columns the platform writes or calculates by itself — Last updated, creation log, formula, mirror, lookup, auto-number, item ID, progress, button — never count and are never stored, and empty columns are not stored at all. As controller you can narrow the watched list to specific columns on the Setup tab; the approval engine works identically.
Written down (3) — the board rule	Who signs off by default (monday.com user IDs), whether any one signature is enough or everybody has to sign, and which columns count as a change. A board that sets nothing still works.
Written down (4) — the subscription status	What monday.com reports about your subscription, so the app can check at runtime whether it is running, as monday.com requires every app to do: plan identifier, whether it is a trial, the date it runs to, the billing period, the pricing version, the seat limit and which notice was last received. This is account-level, not personal, and contains no payment details of any kind — no card, no billing address, no amount. monday.com handles all payment; none of it reaches the app.
Written down (5) — the authorisation key	The key monday.com issues when your account authorises the app, held per account in the platform's own encrypted vault. Used only on the server, to read the item being decided and to post the decision to that item's Updates. Never sent to the browser, never returned in a response, never written to a log, deleted on uninstall.
Read and immediately discarded	When your account installs or uninstalls the app, or changes its subscription, monday.com sends the app a notice containing the email address, name and country of the person who clicked and your account's name and web address. The app reads only the kind of notice and the numeric account ID and discards the rest — it is written neither to storage nor to a log line. This is enforced by the code and covered by the automated test suite, which fails if any other field starts being kept.
Never stored	No names — every name on screen is read live from monday.com and is gone when the screen closes. No email addresses, phone numbers, profile pictures, job titles or team memberships. No files or attachments, and no updates or comments written by your team. No monday.com account name or web address. No passwords or payment details. No analytics, no tracking, no cookies of ours, and nothing stored in the user's browser.
Special category data	The app processes none by design, and it can still end up holding some if your people put it there. Nothing in the app asks for health, biometric or any other Article 9 data, and no field exists for it. Two fields, however, hold whatever a person types or a board contains: the free-text reason written when an item is sent back, and the preview of a watched column. What we do about it: the app tells the person writing a reason that colleagues will read it, and that reason is also posted to the item's Updates, where the same people would read it anyway. As controller, instruct your staff not to put sensitive personal data into those fields, and exclude from the watched column list any column your organisation treats as sensitive.
Artificial intelligence	The app publishes six actions that the assistant already present in your monday.com account can call. We call no AI service, hold no AI key and pay for no AI usage, and nothing from your account is used to train any model by us or by any service of ours, because there is none. The assistant itself is monday.com's, under your agreement with them. Every rule that applies to a button applies to an action: the same server code decides, so an action cannot be used to bypass who may sign off or an expired subscription.

3. Where the data is held, and international transfers

The app runs on monday code, monday.com's own hosting for marketplace apps, in the European Union region, and stores its records in the storage that platform provides. There is no server of ours anywhere in the path, no database of ours and no backup of ours.

We carry out no international transfer of your data, because we never receive it outside that platform. Any transfer that occurs is monday.com's own, under monday.com's terms with you and monday.com's own transfer safeguards.

4. Sub-processors

We use one sub-processor for the data in the app:

Sub-processor	What it does	Where
monday.com Ltd (and its group companies)	Provides the marketplace, the hosting that runs the app, the storage that holds the records described in section 2, and the vault that holds the authorisation key.	monday.com's European Union region.

monday.com is already your own data processor for monday.com itself, under the agreement you hold directly with them, and their own sub-processors apply under that agreement. We add no other sub-processor: no analytics provider, no error-reporting service, no hosting provider of ours, no AI service.

One thing to be aware of separately: if you or your staff email our support address, that correspondence sits in a Google-hosted mailbox, which processes it as a sub-processor of that correspondence only. It never contains data pulled out of your monday.com account unless you choose to put it in the email yourself.

If we ever intend to add or replace a sub-processor, we will publish the change on this page and update the date at the top at least 30 days before it takes effect. If you object on reasonable data-protection grounds within that period, you may uninstall the app and end this DPA; billing stops under monday.com's rules.

5. Security measures

The app's security rests on a deliberate design decision: it holds little, it holds it in one place, and it has nowhere else to send it. Concretely:

No infrastructure of ours. No servers, no database, no backups, no logs outside monday.com's platform, no administration console. There is no system of ours for an attacker to breach, and no credential of ours that would unlock your data.
No outbound traffic. The app calls no external service. The only network it speaks to is monday.com's own.
Two permissions, and no more. The app asks your account to authorise reading boards and writing updates. It does not ask for permission to read your updates, your files, your assets or your users' profiles, so it could not read them if a future version tried.
Identity comes from monday.com, signed. The app has no login of its own and no password to steal. Every request carries a token issued and signed by monday.com; the server verifies that signature before doing anything, and takes who you are, which account you belong to and whether you administer it from that token only — never from anything the browser claims.
Item content is read on the server, never accepted from the browser. This is the security property the product depends on: if the browser reported what an item says, anyone with the developer tools open could keep a green stamp on an item they had just changed.
Authorisation is enforced on the server. Who may send an item for approval, who may sign off, who may change the board rule and who may erase are checked in server-side code on every single call, not by hiding a button. A crafted request is rejected rather than made hard to click. Where the platform cannot be asked whether a person may edit a board, that is treated as "not verified", which is not the same as "yes".
The same rules apply to the assistant actions. They call the same server code as the buttons; no rule about authority or billing is written a second time in a place a harness would not reach.
One account cannot reach another. Records are addressed by the account ID taken from the signed token, never from the body of a request, and the test suite proves that one account cannot read, decide on, or erase another's data.
The erasure endpoints are narrower than the rest. Only an administrator of the monday.com account can erase everything or erase one person; somebody merely named as an approver cannot, so nobody can make a decision of their own disappear. A token that is silent about administrator status is refused rather than assumed.
The platform notice endpoint is behind a secret address. The lifecycle notices from monday.com arrive at an address that ends in a secret held in the app's vault and registered only in monday.com's developer console. It is never reachable from any screen. This exists because those notices are signed with the same key as ordinary user tokens and carry the same fields, so nothing else would distinguish a genuine notice from a forged one.
Encryption. Data is encrypted in transit and at rest by monday.com, as part of the platform. The per-account authorisation key sits in the platform's encrypted vault, separated by account.
No developer access. We cannot read your data. There is no dashboard, no export route and no support back door that would let us. To help with a support question we rely on what you tell us, or on a screenshot you choose to send.
Confidentiality. Only one person — the sole trader named at the top of this page — develops and supports the app, and is bound by a duty of confidentiality in respect of anything learned about your organisation. There are no employees or contractors with access.
Tested behaviour. The rules that decide what a version is, when an approval falls, who may sign, what the subscription unlocks and what may be erased are covered by an automated test suite — 1,051 cases at the time of writing — run before every release. The rules that matter for safety are proven by planting the defect deliberately and watching the suite fail.

Being straight about the limits: we hold no security certification — no ISO 27001, no SOC 2 — and we do not claim one. We do not run a bug bounty programme or commission penetration tests. What we offer instead is a much smaller attack surface than an app with its own servers, and the platform-level assurances monday.com publishes for apps hosted on its own infrastructure.

6. Who can see what

The app shows a person what monday.com already lets them see. An item they cannot open in monday.com is an item the app will not show them.
People who can edit a board can send items for approval and change the board rule.
Only the people a request names can sign it off or send it back.
Only an administrator of the monday.com account can erase everything, or erase one person.
We cannot see any of it.

7. Helping you meet your own obligations

Because we hold no copy of your data, everything you need you can do yourself, immediately, inside the app. We will assist where you cannot.

Access. The Setup tab, for an account administrator, lists what this app keeps about people: every user ID held, and where each one appears. The board report shows every item's state, who still has to sign, and the last decision; the history on an item shows every decision taken on it, newest first.
Rectification. The board rule, the default approvers and the watched column list are edited in the app at any time and take effect immediately. A wrong decision is corrected by taking the right one — the history keeps both, on purpose, because an audit trail that can be quietly rewritten is not one.
Erasure. Three routes, all of which delete rather than mark as deleted: uninstalling the app, which erases everything for your account automatically; Delete everything this app keeps on the Setup tab, available to an account administrator, which asks for the word DELETE to be typed and checks it again on the server; and erasing one individual, also on the Setup tab, which removes that person's identity from the app's records.
When one person is erased, their decisions stay in the history without their name, and anything still waiting on them stops waiting. That split is deliberate: being erased must not be a way to make an approval disappear, and an item must not wait forever for somebody who is no longer there. Erasure is never blocked by billing.
Restriction and objection. Uninstalling the app stops all processing at once; nothing of the app keeps running in the background.
Requests we receive directly. If a data subject contacts us instead of you, we will not answer on your behalf. We will tell them to contact their employer and, unless it is unlawful to do so, let you know without undue delay.
Impact assessments and consultations. On written request we will provide the information about the app that you reasonably need for a data protection impact assessment or a consultation with your supervisory authority.

8. Deletion at the end

When your account uninstalls the app, monday.com notifies the app and the app erases everything it holds for your account immediately and automatically, including the authorisation key. We keep no copy anywhere, because we never had one, so there is nothing further for us to return or destroy. If you require written confirmation of deletion, ask and we will provide it.

Keep what you need first. Everything the app holds is erased, including the approval history; your monday.com items themselves are untouched.

9. Personal data breach

If we become aware of a personal data breach affecting personal data processed through the app, we will notify you without undue delay and in any event within 72 hours of becoming aware. The notice will describe what we know, the likely consequences and what is being done. We will assist you with your own notification duties under Articles 33 and 34 GDPR.

Two honest points about how that notice reaches you. First, the app deliberately stores no email addresses, so we will contact you using the contact details monday.com provides to us for your subscription, and any address you have written to us from. If you want breach notices to reach a specific mailbox — a security team, a DPO — email that address to us and we will record it against your subscription. Second, because the data lives in monday.com's infrastructure and not ours, a breach of the underlying platform would be detected and notified by monday.com under your agreement with them, and we would very likely learn of it at the same time you do.

10. Information and audit

On reasonable written request, and no more than once a year unless a breach or a supervisory authority requires otherwise, we will provide the information you need to verify our compliance with this DPA — what the app stores, which permissions it holds, and how the access rules work. Being straight again: as a sole trader we cannot host an on-site audit, and there is no infrastructure of ours to inspect. For the platform layer, monday.com's own published compliance material is the applicable evidence.

11. Liability, term and law

This DPA takes effect on installation and ends when the app is uninstalled and any remaining data is deleted, whichever is later. Where its terms conflict with the Terms of Service on a matter of data protection, this DPA prevails. The liability limits in the Terms of Service apply to this DPA, except where the GDPR does not permit them to. This DPA is governed by the laws of Ireland.

12. Changes

If this DPA changes, the date at the top changes and the new version is published here. For changes that reduce your protections, or that add or replace a sub-processor, we give 30 days' notice on this page before they take effect.

13. Contact

Item Approval Workflow is supplied by Kauê Natan Gonçalves Bidim, trading as Saoirse Software, in Ireland. Data protection questions, requests under this DPA and security reports all go to help@saoirsesoftware.com. Emails reach the person who writes the code.

← Back to Item Approval Workflow