Privacy Policy

1. Who is responsible for what

For everything inside your Microsoft 365 tenant, you are the data controller and IMPRESSIONSDIRECT360 LLC is a processor acting on your behalf. You decide what data exists, who may see it, and how long it is kept. We do not sell your tenant content, share it for advertising, or use it to train models. We do keep operational records derived from it — details our automations extract from the mail they handle — because that is how the service runs and bills; section 6 sets out exactly what those records contain and where they sit.

We act only on your documented instructions, which are:

• the automations you enable, configured as written down in your onboarding record;
• the support requests you raise with us; and
• anything else you ask us in writing to do in your tenant.

If we believe an instruction would break the law, we will say so before acting on it rather than quietly carrying it out. For your ImpressionsDirect360 account, billing records, saved projects, and product records, we are the controller and the sections above apply instead.

You buy and hold your own Microsoft 365 licences, in your own name. We do not resell Microsoft licences today — the tenant, the subscription, and the billing relationship with Microsoft are all yours.

2. What data we process

Only what the automations and support you asked for actually touch:

• Mail content and metadata: the body of messages an automation is built to handle, plus sender, recipients, subject, timestamps, and attachments.
• Calendar entries: the events, times, locations and attendees on the day's calendar for a mailbox you nominated, read so a morning brief or meeting-prep summary can be written. Our calendar permission is read-only — no automation we run creates, changes or deletes a calendar entry.
• Files: documents in the SharePoint sites a workflow files into or reads from. No automation we run today targets a personal OneDrive.
• Directory information: the display names and email addresses of users in your tenant, read so that setup can offer you a list of your real mailboxes to choose from instead of asking you to type addresses. We do not read group membership.

The data subjects are your own staff and the people who correspond with them. You nominate the mailboxes, sites, and calendars the automations run against, and that is what they are configured to touch. Be clear about what that limit is: it is a setting in our configuration, not a boundary Microsoft enforces on us. The permissions our application actually holds are tenant-wide. Section 5 says how wide, and what you can do in your own tenant to narrow it.

The permission set is not negotiated per customer. There is one multitenant application with one fixed set of Microsoft Graph application permissions — Mail.ReadWrite, Mail.Send, Calendars.Read, Sites.ReadWrite.All, and User.Read.All — and every customer consents to the same five. Microsoft shows them to your administrator on its own consent screen before anything is approved. The permission list on our Microsoft 365 security page lists these same five. If the two ever differ, this page is the one to believe — and the Microsoft consent screen in your own tenant beats us both.

We do not ask for special categories of personal data and the service is not designed around them. We cannot stop such data arriving in a mailbox we process, so if it routinely will, raise it with us before onboarding — see the certification note in section 5.

3. What we use it for — and what we never do with it

Your tenant content is processed to deliver the automations and the support you configured, and to keep the operational and billing records that running them produces — described in section 6. We do not sell it, rent it, or share it for advertising, and we do not use it to train models — ours or anyone else's.

The AI paths, precisely. Qwen 3.8 Max is used only to create and refine websites through Vercel AI Gateway, and those calls require zero-data-retention-capable routing. The storefront assistant, logo prompts, and content tools use Google's Gemini API on Google's paid tier. A prompt is processed by the provider assigned to that feature and its response is returned to you. We keep no extra copy of the prompt beyond the customer records you choose to save and the operational record described in section 6.

Every AI action is metered per customer, because your plan includes a monthly allowance. Metering records that an action ran, for which customer, and its size for cost attribution — it is a billing record, not a copy of what the action was about.

4. Subprocessors

The vendors that can touch your data on our behalf are listed, with what reaches each one and where they process it, at /trust/subprocessors. That page is the live list — we keep it current rather than restating a copy here that could drift out of date, and it carries the date it was last reviewed.

We use no subprocessor that is not on that page. When we add one, the page is updated. If you object to a new subprocessor, email support@impressionsdirect360.com and we will explain what it does and offer an alternative where one exists. Where none exists, you can cancel. Cancel anytime — your plan stays active until the end of the period you've paid for. Paid periods are ordinarily non-refundable; legal and billing-error exceptions apply.

5. The security measures we actually have

Described as they are today, not as a wish list:

• Tenant-wide Graph permissions — and what that actually means. The five permissions in section 2 are Microsoft Graph application permissions, and application permissions are tenant-wide by design. Once your administrator consents, the application can technically reach every mailbox, every calendar, and every SharePoint site in your tenant — not only the ones you nominated. Our automations are configured to touch only what you nominated, and that is what they do; but that is our configuration, not a wall you can inspect. We are not going to call this least privilege, because it is not.
• The narrowing you can apply, and the gap in it. The limit that is genuinely enforced is one you set inside your own tenant: an Exchange ApplicationAccessPolicy that restricts our application to a named security group of mailboxes. We recommend it to every customer, and we will help you apply and test it — ask and we will send you the exact commands to run. Its reach is Exchange workloads only, which means mail and calendar. There is no equivalent for SharePoint or OneDrive. Narrowing those would require the Sites.Selected permission model and we have not implemented it, so for as long as we hold Sites.ReadWrite.All, every SharePoint site in your tenant remains technically reachable.
• A single named application, consented to by your own admin. Your Microsoft 365 administrator grants access to one named ID360 application from inside your own admin center. There is no shared admin account, and we hold no password of yours. You can withdraw that consent yourself at any time, without notice to us, and our access ends the moment you do.
• Per-tenant consent and per-tenant tokens — not per-tenant secrets. Said precisely, because the difference matters: there is one application registration, with one client ID and one client secret, shared across every customer. What is separate per customer is your consent and the access token it produces. A token is issued for one tenant and rejected everywhere else, so a token minted for your tenant cannot read anyone else's data, and revoking your consent affects only you. What we cannot claim is separate keys: if that one shared secret were ever compromised, it would matter to every tenant that has consented, not to one.
• Secrets in the platform's secret storage. Tokens and keys live in the hosting platform's own secret store, not in source code or checked-in configuration.
• Automation actions are recorded server-side; ad-hoc access is not. When an automation acts in your tenant, it writes a record on our side — what it did, for which customer, and when — and you can read it yourself in your dashboard under Microsoft 365, where it is shown as a plain list of what ran and when. It covers automated actions only. When a person here signs in to look at something while handling a support request, we do not separately log that; the record of it is Microsoft's own audit log inside your tenant, which is yours to query without involving us.
• Encryption in transit. Traffic between us, your tenant, and our subprocessors runs over TLS.

What we do not have. We hold no SOC 2 report, no ISO 27001 certification, and no HIPAA attestation, and we have not been audited by a third party. Card payments are handled by Stripe, so card data never reaches our servers; that is Stripe's compliance, not ours. Our subprocessors hold certifications of their own — those are theirs, and we do not present them as ours.

Granular delegated administration (GDAP) is not what is in place today. GDAP is created through Microsoft Partner Center and our reseller enrolment has not completed, so we will not describe our access as delegated administration until it is true. Today it is the application consent described above: it has no built-in expiry date, and it ends when you revoke it.

6. Where the data sits

• Mail bodies and the documents themselves stay in your own Microsoft 365 tenant, in the Microsoft region you chose when you set it up. We do not copy message bodies or files into a store of ours to make an automation work.
• Details extracted from that content do reach us. Each time an automation acts, it writes an operational record into our own PostgreSQL database, running in Azure in a United States region. Depending on the automation, that record holds: the vendor name, invoice number, and amount taken from an invoice; the merchant and amount taken from a receipt; a message identifier, the sender's domain rather than the full address, and the category and urgency a classifier assigned to a lead; the mailbox addresses involved; a link back to the document we filed in your tenant; and counts, such as how many unread messages or meetings a digest covered. It is a description of what happened rather than a copy of the mail — but it is extracted from your mail, it is personal data, and it sits on our infrastructure rather than yours.
• Our other operational records — automation run history and run state, AI usage metering, and your account and billing records — are held in the same United States systems.
• AI processing happens at the provider named on the subprocessors page. Website design uses Qwen through Vercel AI Gateway; the other named AI tools use Gemini. If either path changes, that page changes with it.

The row-by-row version, including which vendor handles which category, is on the security page.

7. Keeping, returning, and deleting data

Your content. Mail bodies and documents live in your tenant and we hold no copy of them, so there is nothing of that kind for us to return at the end. We do not delete them. The single exception is an automation you configured to archive or delete on your own retention policy, with your sign-off; that acts on your instruction, not ours.

What we do hold is not nothing. The operational records in section 6 contain details extracted from your mail, and those are on our side. You can ask us for a copy of them, and you can ask us to delete them.

When the service ends. You revoke the application's consent in your own admin center and our access stops immediately; scheduled automations stop with it. Your tenant, licences, mail, files, and anything an automation filed for you are all unaffected and stay exactly where they are.

How long we keep our operational records. We keep them while your account is open, and afterwards where we still need them — billing, tax, and accounting records, and the automation record itself. There is no automated deletion schedule for any of it today. Nothing expires these records on a timer; they stay until somebody deletes them, and we are not going to claim a retention clock we do not run. Ask us what we hold about your account and we will send you a copy, delete what we are able to delete, and say plainly what we have to keep and why.

Your automation record. Email support@impressionsdirect360.com and we will send you the record of what our automations did in your tenant over the period you name. For access by a person here rather than by an automation, the record is Microsoft's audit log in your own tenant, not ours — see section 5.

8. Personal data rights, and telling you about a breach

Rights requests. If someone exercises a data protection right — access, correction, deletion, export — and you need our help, email support@impressionsdirect360.com. Because the mail and files sit in your own tenant, you can often action a request yourself with Microsoft's tools faster than we can; where you cannot, we will help you find, export, correct, or delete it. The extracted details in our own operational records are ours to search, not yours — tell us the request covers those too and we will include them. As a processor we answer to you, not to your staff or your customers directly, so we will refer a request that reaches us straight to you unless you ask us to handle it. Requests are worked during our support hours, Monday–Friday, 9:00 AM – 6:00 PM Central, under the response target for your plan.

Breach notification. If we become aware of a personal data breach affecting your tenant data, we will notify you without undue delay with what we know at the time: what happened, which of your data was involved as far as we can tell, what we have done, what we are still doing, and anything we need from you. If the picture is incomplete we will say so rather than wait for a tidy story, and we will follow up as it changes.

We do not quote a fixed notification clock in hours, because we do not yet run the round-the-clock monitoring that would let us honour one. How to report a suspected incident to us, and what we do in the first hours, is on /trust/incident-response.

9. Who to contact about this addendum