Privacy Policy

ITSailor is the trading name of Michal Jatczak, a sole trader registered in Malta, operating from Level 1, Unit 60, Door No 63, Connecticlub Business Center, Triq Il-Ballut (Zona Industrijali, Mosta), MST 4001, Mosta, Malta. Malta VAT number MT32760411, DUNS number 507601021. Microsoft AI Cloud Partner Program Authorized partner, PLA ID 7113951. References to "we", "our", "ITSailor" in this Policy mean Michal Jatczak T/A ITSailor.

This Privacy Policy explains how we collect, use, and share personal data when you (a) visit itsailor.io, (b) use any of our free diagnostic tools, (c) purchase a paid workshop or eBook, (d) sign up for our SaaS products (SEAWALL FinOps Engine, HELMGATE approved admin actions, DECKLOG knowledge operations - currently in sales MVP phase), or (e) contact us for consulting work.

We act as a data controller (GDPR Article 4(7)) for the data described below. This Policy is the controller-side transparency notice required by GDPR Articles 13 and 14 for the data we process as controller. Where we act as processor (see section 11), the Article 13 and 14 information for the individuals concerned is provided by you as controller.

For personal data you instruct us to process inside your own systems (for example during a paid consulting engagement), we act as a data processor (Article 4(8)). Nothing on this page, and no purchase by itself, appoints us as your processor. Where an engagement requires us to process personal data on your behalf, the terms required by Article 28(3) are agreed with you during scoping, before that processing begins. We do not attach a standard Data Processing Agreement by default, which is the same position our trust register publishes. Section 11 describes the processing that runs today without separately agreed Article 28 terms, and what to do if your organisation needs them first.

One row per category, with the six things Articles 13 and 14 make us tell you on the same line: what we collect, why, the lawful basis with its article, how long we keep it, and who receives it. Two retention rules are not per-category and live in section 05 instead; the cells that rely on them say so.

One category is missing from that table on purpose. The directory data our tenant connectors read from your Microsoft 365 or Google Workspace is not data we hold as controller: you are the controller and we are your processor for it. Section 11 covers it connector by connector, including what each one reads, what it keeps, and for how long.

AI features: what is sent, to whom, and on what basis

We use two AI providers, both named in section 03. This is the complete per-path picture, written from the code that makes the call rather than from a product description.

• Free diagnostic report (OpenAI). When you submit the email deliverability check, the Microsoft 365 licence waste audit or the offboarding risk profiler in order to receive a report, the tool inputs and the computed results are sent to OpenAI to write it. This is not a separate opt-in: asking for the report is what starts it. Your email address is deliberately kept out of the prompt and is used only to deliver the finished report. Legal basis: Article 6(1)(f), our legitimate interest in delivering the report you asked for (see section 02, and your right to object).
• SaaS Auditor Captain's Brief and SaaS Command Brief (Anthropic). Only aggregate figures are sent: counts, money, reason buckets and third-party application names. The per-user identity list is assembled in your browser and does not form part of the payload. Legal basis: Article 6(1)(f) when you use the free tool, Article 6(1)(b) where the feature forms part of a paid subscription.
• Contract extraction in the spend register (Anthropic). If you upload a contract, order form, quote or renewal notice, the complete PDF (up to 8 MB) is transmitted as it is. It is not de-identified and not redacted: whatever the document contains, including signatory names and contact details, goes with it. We do not store the file. Nothing is sent unless you choose to upload. Legal basis: Article 6(1)(f) when you use the free tool, Article 6(1)(b) where the feature forms part of a paid subscription.
• Ops Log article drafting (Anthropic). Internal editorial use. The input is our own session and source material; it is not a customer data path.

HELMGATE and DECKLOG are in sales MVP and run no AI feature over customer data today. If that changes, this section and the subprocessor list in section 03 are updated first, under the 30-day notice described there.

Where we get your data from someone else (Article 14)

One category does not come from you. When an organisation buys Microsoft licences through our marketplace checkout, that organisation gives us the name and business email address of the person who will sign the Microsoft Customer Agreement, and of any tenant administrator it names. If that is you, here is the Article 14 notice:

• Source. The organisation placing the order. We did not obtain your details from a public source, a data broker or any list.
• Categories. Name, business email address, and the role you hold in the order (MCA signatory, tenant administrator).
• Purpose and basis. Placing and provisioning the licence order. Article 6(1)(b) where you are a party to the arrangement, otherwise Article 6(1)(f): our and the purchasing organisation's legitimate interest in getting the tenant activated for the person Microsoft requires to be named.
• Recipients. Microsoft and Pax8, as described in section 03.
• Retention and rights. As set out in sections 05 and 06. You can object under Article 21 and ask for erasure under Article 17 without asking the organisation first.

We provide this notice at the latest when we first contact you (GDPR Article 14(3)). A company registration number is data about the entity, not about a person, so it is outside this notice.

• Performing the contract (Art. 6(1)(b) GDPR) - account creation, billing, support, and delivery of paid workshops, eBooks, and SaaS subscriptions.
• Legitimate interests (Art. 6(1)(f) GDPR). The interests we actually pursue, named rather than summarised: keeping the service available and free of abuse; understanding in aggregate which pages and tools are useful, so we build the next thing on evidence; and replying to a business enquiry you chose to send us, including the AI-written report you asked for. Contact confirmations are transactional messages about that request, not marketing. We carry out a balancing test before relying on this basis for a purpose and record the outcome; ask for a summary of any of them at privacy@itsailor.io. You can object to any of this processing under Article 21, described separately in section 06.
• Legal obligation (Art. 6(1)(c) GDPR) - tax and accounting records under Maltese law (7-year retention); responding to lawful requests from regulators or courts.
• Demonstrating consent (Art. 6(1)(c) GDPR read with Art. 7(1)) - the cookie consent audit records described in section 01. We are required to be able to show that consent was given, which we cannot do without keeping a record of the decision.
• Consent (Art. 6(1)(a) GDPR) - optional newsletter; non-essential cookies (subject to your cookie banner choice); optional AI feature opt-ins. You can withdraw consent at any time from your dashboard or by emailing privacy@itsailor.io.

Whether you have to give us the data, and what happens if you do not

Article 13(2)(e) requires us to tell you which data you are obliged to provide and what follows if you withhold it. Per category:

• Free tools, the contact form and the newsletter. Entirely voluntary. There is no statutory or contractual requirement to give us anything. The only consequence of withholding is that no report, no reply and no newsletter is sent.
• Workshops, eBooks and SaaS subscriptions. Name, work email and billing details are a contractual requirement: we cannot invoice you or deliver the purchase without them, so the order cannot proceed. Billing country is additionally required as place-of-supply evidence under Article 24b of Council Implementing Regulation (EU) 282/2011, and those records are retained for 7 years under Maltese tax law.
• CSP licence orders. The MCA signatory's name and email are required by Microsoft before a tenant can be activated. A VIES-verifiable VAT ID is required by us to apply the reverse charge under Article 196 of Directive 2006/112/EC. The company registration number and the Microsoft tenant ID are required to provision the order at all. These are contractual requirements arising from the vendor terms and our tax position, not statutory obligations we impose on you. If any of them is withheld the order is not placed and any payment taken is refunded.

We share personal data with the following subprocessors strictly to deliver the Services. Where data leaves the EEA we rely on the European Commission's Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) with every non-EEA subprocessor, and additionally on the EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795) where the subprocessor self-certifies under it. Technical measures apply alongside both: TLS 1.2 or higher in transit, and encryption at rest. See section 04 for detail.

Every row below is rendered from one register in our source, the same register the trust page and the connector scope inventory read. Which block a party appears in is decided by the role recorded against it, not by which list somebody typed it into, so the three pages cannot publish different answers to who receives your data.

• Stripe Payments Europe Ltd. - Payment processing and subscription billing. Stripe holds two roles at once and we disclose both. It is our processor when it executes a payment, a subscription charge or a refund on our instruction. It is an independent controller, determining its own purposes and means, when it uses the same payment data to monitor and prevent fraud on its platform, to manage financial loss and security risk, to meet its own anti-money-laundering and know-your-customer obligations, to run its own billing and relationship processes, and to analyse and develop its products. Paying us therefore also discloses your payment data to Stripe as a controller in its own right, and Stripe's own privacy policy governs that part rather than this one. See Stripe's Data Processing Agreement.Establishment: Ireland (EEA). Where the processing happens: Ireland, inside the EEA, with routing to Stripe group entities outside the EEA. Transfer basis: Standard Contractual Clauses (EU) 2021/914 for any routing outside the EEA; Stripe also self-certifies under the EU-US Data Privacy Framework.
• Resend, Inc. - Transactional email delivery for workshop provisioning, eBook delivery, diagnostic reports and SaaS notifications.Establishment: United States. Where the processing happens: United States, outside the EEA. Transfer basis: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
• Upstash, Inc. - Managed Redis storage for newsletter consent records, contact idempotency state, confirmation state, rate limits, scan sessions and scheduled delivery jobs.Establishment: United States. Where the processing happens: United States, outside the EEA. Transfer basis: Data processing addendum and the Standard Contractual Clauses (EU) 2021/914. No framework listing is claimed.
• Hetzner Online GmbH - Production server hosting and Storage Box backups. Houses our n8n automation, Directus backend, Postgres databases and SaaS application data.Establishment: Germany (EEA). Where the processing happens: Falkenstein, Germany, inside the EEA. Transfer basis: None needed. The processing does not leave the EEA.
• Cloudflare, Inc. - DNS, CDN and Zero Trust Tunnel for our self-hosted services.Establishment: United States. Where the processing happens: A global edge network outside the EEA; EU traffic is served from EU edge nodes. Transfer basis: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
• Vercel, Inc. - Frontend hosting and edge request logs for itsailor.io.Establishment: United States. Where the processing happens: Serverless functions execute in Frankfurt, Germany (fra1), inside the EEA. Static assets and request logs are served from a global edge network outside the EEA. Transfer basis: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
• Plausible Insights OÜ - Opt-in, cookie-free website and conversion analytics. We suppress private routes, form contents, arbitrary query parameters and dynamic report identifiers before an event is sent. Plausible is not used for advertising or cross-site profiling.Establishment: Estonia (EEA). Where the processing happens: Inside the EEA. Transfer basis: None needed. The processing does not leave the EEA.
• GitHub, Inc. - Private repository hosting for client deliverables (Terraform modules, Intune baselines, SOPs), and authentication for the DevEx Maturity Scan tool.Establishment: United States. Where the processing happens: United States, outside the EEA. Transfer basis: EU-US Data Privacy Framework, self-certified under the Microsoft umbrella, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
• Anthropic (Claude API) - Generation of the SaaS Auditor Captain's Brief and SaaS Command Brief from aggregate scan figures, with no directory identity in the payload; extraction of commercial terms from a contract, order form, quote or renewal notice you choose to upload, where the complete PDF of up to 8 MB is transmitted as it is and is not de-identified; and internal drafting of Ops Log articles. Retention is governed by the provider's data processing agreement. The provider's terms provide that API inputs are not used to train models.Establishment: Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Where the processing happens: Outside the EEA. Transfer basis: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
• OpenAI (API) - Generation of the diagnostic report emailed to you after a free-tool submission, and of the Tenant Monitor report for subscribers. Until 21 September 2026 this row also covered a weekly Platform Health Briefing generated from a repository a subscriber enrolled for monitoring; that feature and the code behind it were removed on that date, and nothing replaced it. Retention is governed by the provider's data processing agreement. We do not publish a retention figure of our own for this path: the period is set by the provider and can change without notice to us, and a number we cannot hold to is worse than no number. The provider's terms provide that API inputs are not used to train models.Establishment: Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Where the processing happens: Outside the EEA. Transfer basis: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
• Cal.com - Scheduling for discovery calls, product demos and paid workshop sessions. When you open a booking link we send you, the name, email address, chosen slot, timezone and any notes you type are processed by the scheduling provider on our behalf.Establishment: Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Where the processing happens: Outside the EEA. Transfer basis: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
• DocRaptor - Rendering the PDF of an eBook you have purchased. The render request carries the publication HTML, which includes the single-user licence line bearing your email address. Retention is governed by the provider's data processing agreement.Establishment: Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Where the processing happens: Outside the EEA. Transfer basis: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.

Four rows above (Anthropic, OpenAI, Cal.com, DocRaptor) name the service rather than a corporate entity, and their establishment line says so. That is deliberate: we do not print a contracting entity or a certification we have not verified against the provider's own data processing agreement. Write to privacy@itsailor.io and we will tell you which entity we contract with and on what transfer basis.

Recipients that are not our subprocessors

The parties below also receive personal data because of something you do with us, but they do not process it on our instruction. Listing them as subprocessors would tell you we control what they do with your data, and we do not. The CSP Marketplace Terms section 07 states the same roles for a licence order; this block is the Privacy Policy saying the same thing rather than a second answer.

• Google LLC (reCAPTCHA) - Abuse and fraud risk scoring on our public contact form and our free scan-request form. Those two pages load the reCAPTCHA v3 script from www.recaptcha.net into your browser, so your browser sends device, network and interaction data to Google directly, and Google sets the _GRECAPTCHA cookie, before you submit anything and without that data passing through our systems. Google does not receive it on our instruction and we do not determine what Google does with it afterwards, so Google is not our subprocessor. Following the Court of Justice in Fashion ID (C-40/17), we are a controller for the collection of that data and for its disclosure by transmission to Google, because we embedded the script that causes both. When you submit the form, our server sends the resulting token back to Google to read the score; that request carries the token and our own secret and no personal data of yours, not your IP address and none of what Google collected in the browser. Whether a transfer instrument is required here, and which label finally fits this disclosure, is a question for counsel; this row describes what happens rather than deciding it. See third-party cookies in the Cookie Policy.Establishment: United States. Where the processing happens: Outside the EEA. The data goes from your browser to Google and does not pass through our systems. Transfer basis: No transfer instrument of ours covers this path, and we claim none. Whether one is required is with counsel.
• Microsoft Ireland Operations Limited - The licensor and platform operator for Microsoft 365 licences you choose to buy through us via the Pax8 marketplace. Microsoft processes the content of your tenant as your processor under the Microsoft Products and Services Data Protection Addendum, on your instructions and not on ours. Buying a licence from us gives us no access to your tenant content and does not make Microsoft our subprocessor.Establishment: Ireland (EEA). Where the processing happens: Your own tenant, under the agreement you hold with Microsoft. The contracting entity is inside the EEA. Transfer basis: Not ours to state. Microsoft processes tenant content on your instruction under its Data Protection Addendum with you, so your agreement governs that transfer and not ours.
• Pax8 Inc. - Our wholesale supplier and provisioning rail for Microsoft licensing. We transmit your order data to Pax8 so the order can reach Microsoft, and Pax8 receives it as an independent controller in its own right to fulfil the wholesale order. Only order and billing metadata reaches Pax8; your Microsoft tenant data does not.Establishment: Netherlands (EEA), for the EU wholesale operation. Where the processing happens: Netherlands, inside the EEA. Transfer basis: Not ours to state. Pax8 receives the order data as an independent controller, so its own position governs that processing.

On the reCAPTCHA row specifically: the _GRECAPTCHA cookie Google sets in your browser is itemised in the Cookie Policy at the link above, and Google describes its own processing in its privacy policy. We claim no Framework certification for that path, because we have verified none.

Personal data at rest is stored inside the EU/EEA (Malta, Germany, Ireland, Netherlands), and our serverless functions execute in Vercel's Frankfurt region. Some personal data still reaches US-headquartered subprocessors: short-lived sign-in and scan state held in the United States, transactional email, the model that drafts free-tool reports, and code hosting. For each such transfer we rely on a Chapter V GDPR mechanism:

• The Standard Contractual Clauses (Implementing Decision (EU) 2021/914, Modules Two and Three as applicable), which we keep in place with every non-EEA subprocessor regardless of its Framework status. If the Data Privacy Framework adequacy decision were suspended or annulled, these clauses continue to govern the transfer without interruption.
• The EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795 of 10 July 2023), in addition, where the subprocessor self-certifies under it. Stripe, Resend, Cloudflare, Vercel and GitHub self-certify, and we check each listing on the public Data Privacy Framework List when we revise this Policy. The four subprocessors added in August 2026 (Anthropic, OpenAI, Cal.com, DocRaptor) are deliberately absent from that group: we do not publish a certification we have not verified, so those transfers rest on the clauses above alone.

Recipients we do not instruct. The clauses above cover what a subprocessor does for us. They do not cover what a party listed in the second block of section 03 does for its own purposes, or the part of Stripe's processing that Stripe determines itself. Microsoft Ireland Operations Limited contracts from Ireland, Pax8's EU operation from the Netherlands, and Stripe Payments Europe Ltd. is established in Ireland. The reCAPTCHA path is the one case where a non-EEA recipient is not covered by an instrument of ours: the data goes from your browser to Google without reaching our systems. Section 03 states that position plainly instead of naming a mechanism we have not concluded, and whether one is required there is with counsel.

Getting a copy of the clauses. Where a transfer relies on the Standard Contractual Clauses, you can obtain a copy of the clauses we have concluded, with commercially confidential terms redacted, by writing to privacy@itsailor.io. You do not have to be a customer to ask (GDPR Article 13(1)(f)).

Consistent with the CJEU's judgment in Schrems II (C-311/18), we apply supplementary technical measures alongside the SCCs: encryption in transit (TLS 1.2 minimum), encryption at rest where supported, and minimisation of the personal data flowing to non-EEA endpoints. A transfer impact assessment (TIA) summary is available to active customers on written request under NDA.

The Framework adequacy decision remains in force. The General Court dismissed the action against it on 3 September 2025 (Case T-553/23, Latombe v Commission), an appeal was lodged on 31 October 2025, and that appeal is pending before the Court of Justice as Case C-703/25 P. Because we keep Standard Contractual Clauses in place with every US subprocessor regardless, a change to the Framework would not interrupt any transfer.

Every retention period is published beside the category it applies to, in the table in section 01: tool and lead data, account and dashboard audit records, contact messages, newsletter subscriptions, cookie consent rows and licence orders each carry their own period there. Two rules cut across the categories rather than belonging to any one of them, so they are stated here and the table points back at this section for them.

• Billing records - 7 years (Maltese tax law). This is not the retention of a category but of a record type, and it applies to the billing part of a workshop, an eBook, a SaaS subscription and a CSP licence order alike, whatever the rest of that order's retention is.
• Security and HTTP request logs - 90 days rolling. The window moves with the calendar rather than with any account or subscription, which is why it is not a per-category period either. Dashboard audit logs are a different thing and are deliberately not in this bucket: they follow the SaaS account row in section 01.

Where a period cannot be fixed in advance we publish the criterion we use instead of a number, which is what Article 13(2)(a) provides for. Erasure requests are handled under section 06, subject to the exemptions in Article 17(3). Tenant data read by our connectors is retained as described in section 11, connector by connector.

If your personal data is subject to the GDPR (Regulation 2016/679) you hold the following rights, exercisable free of charge in the first instance (Article 12(5)):

• Access (Article 15) - request a copy of personal data we hold about you and the processing context.
• Rectification (Article 16) - correct inaccurate or incomplete data.
• Erasure (Article 17) - request deletion (subject to the retention rules published per category in section 01 and to the two cross-cutting rules in section 05, and to any legal-obligation exemptions in Article 17(3)).
• Restriction (Article 18) - limit how we process your data while a dispute or correction is pending.
• Portability (Article 20) - receive your data in a structured, commonly-used, machine-readable format and transmit it to another controller.
• Object (Article 21) - set out separately immediately below, as Article 21(4) requires.
• Withdraw consent (Article 7(3)) - where processing relies on consent under Article 6(1)(a) or 9(2)(a); withdrawal does not affect prior lawful processing.
• Not be subject to solely automated decisions (Article 22) - see section 10. We do not run such decisions today.
• Lodge a complaint (Article 77) with the Information and Data Protection Commissioner of Malta (IDPC) - our lead supervisory authority - or with the supervisory authority of your EU/EEA Member State of residence.

We use a minimal set of strictly necessary cookies for authentication (session token) and security (CSRF). Under Article 5(3) of the ePrivacy Directive (2002/58/EC, as amended by 2009/136/EC) and its Maltese implementation in the Processing of Personal Data (Electronic Communications Sector) Regulations (S.L. 586.01), made under the Data Protection Act (Chapter 586), strictly necessary cookies do not require prior consent. All other categories - functional, analytics, marketing - are opt-in only via the consent banner (CJEU Planet49, C-673/17: pre-ticked boxes do not constitute valid consent).

The full inventory, vendor list, retention, and consent withdrawal mechanism live in the dedicated Cookie Policy. You can change your cookie preferences at any time via the “Cookie preferences” link in the site footer; the change writes an audit row to our consent_log collection and re-prompts on schema-version bumps. What that row contains, why we keep it and how long for are in the table in section 01.

The cookie inventory stays in its own document rather than being folded into this one, and that is a legal distinction rather than a filing preference. Consent to store or read information on your device is governed by Article 5(3) of the ePrivacy Directive, which is lex specialis to the GDPR: it applies whether or not the information is personal data, and it is not satisfied by a legitimate-interest balancing under Article 6(1)(f) (EDPB Opinion 5/2019). Merging the two would blur the consent standard that the storage step has to meet.

Per GDPR Article 32, we implement technical and organisational measures appropriate to the risk of the personal data we process. These include TLS 1.2+ in transit, encryption at rest for databases that support it, principle-of-least-privilege access, dependency scanning, server hardening (UFW, fail2ban, unattended security patches), automated daily backups to off-site Storage Box, and secret rotation procedures. We use the same baseline we deliver to our clients - see our public Architecture Workshop materials for the technical specifics.

We notify the IDPC of personal data breaches within 72 hours of becoming aware where the breach is likely to result in a risk to the rights and freedoms of natural persons (Article 33). Where the risk is high, we also notify affected individuals without undue delay (Article 34).

None of the Services is directed to children. Most Services are sold business-to-business; where a Service is sold to consumers, the rights described in our Terms of Service and Refund Policy apply. We do not knowingly collect personal data from anyone under 16, and we do not rely on a child's consent as a legal basis for any processing. If you believe a child has provided us with personal data, contact privacy@itsailor.io and we will delete it.

Per GDPR Article 22, you have the right not to be subject to a decision based solely on automated processing that produces legal effects concerning you or similarly significantly affects you. Where AI features make recommendations on our platform (e.g. DECKLOG returning ranked documents, AI Readiness Scan scoring), these are advisory only - a human (your team, or ours during a consulting engagement) makes the final decision, so Article 22 does not apply.

Our current AI features are limited-risk at most. Where the EU AI Act (Regulation 2024/1689) applies a transparency obligation to a feature we operate (for example, making clear when you are interacting with an AI system or viewing AI-generated content), we provide that disclosure at the point of use (Article 50). If we ever add a function that would be classified as high-risk under Annex III, we will complete the applicable conformity and transparency steps before that function goes live, in line with the AI Act's phased application dates.

Our SaaS Auditor tool reads your cloud-directory data to produce a posture, licensing, and security report, and, for customers on the paid continuous-monitoring tier, to keep that report current. This section explains exactly what it reads, on what basis, and what we do and do not do with it. It is the specific description of the tenant directory data the scan reads, and on that subject it governs. It does not displace the rest of this Policy: anything we keep outside that read, including the email address you give us to receive a report and the lead record derived from it, is covered by sections 01, 02 and 05 and by the retention periods stated there.

One further connector is described at the end of this section. The SEAWALL Azure collector reads a cloud subscription rather than a directory, and it is a different kind of read in every respect that matters: it asks for no Microsoft Graph permission at all, and what it keeps is not expected to be personal data. It is here because this is the section that covers what we read as your processor, and because a disclosure written before the first customer subscription is read is worth more than one written after.

Our role: data processor, you are the controller

For the directory data the SaaS Auditor reads from your Google Workspace or Microsoft 365 tenant, you are the data controller and we act as your data processor (GDPR Article 4(8)). We process this data only on your documented instruction, which you give by connecting your tenant and authorising the read-only permissions below. Access is strictly read-only: we do not create, modify, or delete anything in your tenant.

Article 28(3) requires that processing to rest on a contract or other legal act between us, and we state the position rather than claim one we do not hold. We do not attach a standard Data Processing Agreement to the free scan or to a self-serve subscription: for both, the authorisation your administrator grants is the whole of the instruction, and it is revocable at any time as set out below. Where you need the Article 28(3) terms in writing, write to privacy@itsailor.io and we agree them with you before we read anything; for a scoped consulting engagement they are agreed as part of scoping.

What we read, and the exact permissions

Google Workspace. Your Workspace administrator authorises a single ITSailor OAuth client. We request three Admin SDK Directory permissions. Two are Google's read-only scopes. The third is not, because Google publishes no read-only variant of it, and the paragraph after this list says exactly what that means:

• admin.directory.user.readonly - the user list and per-user status, last login, and administrator flag.
• admin.directory.domain.readonly - domain and customer account information.
• admin.directory.user.security - per-user third-party OAuth token grants (for Shadow IT discovery) and two-step verification state.

Microsoft 365 (Microsoft Graph). A tenant administrator authorises read-only access. The SaaS Auditor live scan requests exactly these permissions:

• User.Read.All and Directory.Read.All - directory and user data.
• AuditLog.Read.All - sign-in and audit activity.
• Organization.Read.All - tenant and licensing information.
• SecurityEvents.Read.All - Microsoft Secure Score and security findings.
• Policy.Read.All - Conditional Access posture.
• IdentityRiskEvent.Read.All - identity risk signals.
• Application.Read.All - registered and enterprise applications.
• RoleManagement.Read.Directory - directory role assignments, so the report can show which accounts hold administrative roles.
• Reports.Read.All - service usage and activity reports.
• offline_access - a refresh token, so a scheduled re-scan can run for customers on the paid continuous-monitoring tier. It is requested on every live scan, not only on that tier; what happens to the token afterwards is under Retention below. It grants no access to data of its own; it only lets the connector renew its own access token.

We request the minimum permissions needed for the audit and nothing more, and every scope requested is read-only (GDPR Article 5(1)(c), data minimisation). The complete, always-current list of permissions each connector requests, across the SaaS Auditor, the Microsoft 365 Security Scorecard, and the offboarding risk scan, together with the reason for each one and what is stored, is published at itsailor.io/trust/scopes and generated from the code that makes the request, so it stays in sync.

How we handle it

• Pseudonymisation before logging. Before any directory identity is written to our logs, we replace it with a short SHA-256 digest of the form acct_<hex>. Raw identifiers (email addresses, user principal names, display names) are not written to our logs. The digest is computed without a secret key, so it is a pseudonym and not anonymisation: an identifier you already hold can be tested against it. Pseudonymised log data therefore remains personal data in our hands (GDPR Article 4(5) and Article 32(1)(a); Court of Justice, Case C-413/23 P EDPS v SRB, 4 September 2025; EDPB Guidelines 01/2025).
• AI sub-processor. Where you ask for a Captain's Brief or a Command Brief, the aggregate figures behind it are sent to Anthropic to write the narrative; no directory identity is in that payload. Where you upload a contract to the spend register, the complete PDF is sent to Anthropic for extraction. Anthropic is engaged as a sub-processor under GDPR Article 28(2) and 28(4), and the transfer rests on the Standard Contractual Clauses. This addition is announced under the 30-day notice in section 03.
• No model training. Your directory data is not used to train, fine-tune, or improve any AI or machine-learning model, ours or a third party's.
• Retention of the tenant read. The scan result is held on our server for 10 minutes so that the page you are redirected back to can display it, and then it expires on its own. It is not deleted the moment you read it, because a page refresh has to keep working inside that window. For a one-off scan, no record of your directory outlives that window on its own; what our logs keep is the pseudonymised line described above.
• What a monitored tenant keeps between scans. If you enrol in continuous monitoring, each scheduled scan writes a short set of totals against your enrolment, so the next scan can show you what moved: estimated monthly waste, the flagged count, the high-risk and AI counts from shadow IT, the Secure Score percentage, the number of admins without MFA, and the licence overlap count. It also records when the scan ran and how many have run. No name, address, sign-in record or other directory identity is in any of it. These totals are how drift is detected at all, so they persist for as long as the enrolment record does. Ending the enrolment drops the stored credential immediately; the totals stay on the record and follow the retention in section 05, and you can ask us to delete them at any time under section 06.
• Retention of the refresh token. Where you connect Microsoft 365 and the sign-in returns a refresh token, we encrypt it and hold it for 30 minutes, so that you can choose continuous monitoring without connecting a second time. That happens on every completed live scan, not only on the paid tier, and it is skipped altogether when the encryption key for monitoring is not configured, because we will not hold a live credential we could not use. If you do not enrol, the token expires with that window and is never read. If you do enrol in the paid continuous-monitoring (“Tenant Monitor”) tier, the encrypted token is kept for as long as the enrolment is active, and only so the scan can repeat on schedule. When the enrolment stops or the subscription is cancelled, the token is dropped from the record (GDPR Article 5(1)(e), Article 32(1)(a)).
• What outlives the scan. Asking for the report by email is what creates a record that survives the window above. That record holds your email address, the aggregate figures (platform, accounts reviewed, accounts flagged, and estimated monthly and annual waste) and the report written from them. Alongside it we write a comparison snapshot, so that a later scan from the same address can show you what changed; that snapshot holds a little more than the record above, namely the breakdown of why accounts were flagged and the summary risk block, which includes the Secure Score percentage and the number of admins without MFA. We are also notified internally that the scan happened, with your email address and three figures: the platform, the number of accounts reviewed and the number flagged. No directory identity is in any of it. This record is not covered by the 10 minutes above: it is tool and campaign lead data and is kept for the period in section 05. If you do not submit the form, none of it is written.
• You can revoke at any time. Your administrator can revoke our access immediately and independently of us. For Google, remove the grant at admin.google.com or myaccount.google.com; for Microsoft, remove the application under Enterprise applications in Microsoft Entra. Revoking access stops all further reads at once.
• Security. Data is encrypted in transit (TLS 1.2 or higher) and refresh tokens are encrypted at rest, under least-privilege access controls (GDPR Article 32).

SEAWALL: the Azure collector, and why it asks for no permission

SEAWALL's Azure collector reads one or more Azure subscriptions you name and produces a dated evidence pack: what the month cost, what is sitting there unused, and which cost controls existed on that date. For that read you are the controller and we are your processor, on the same Article 28(3) position stated above. The paid Azure pack is not open for self-serve checkout today, so no customer subscription is being read on these terms yet. This describes the collector as it is built.

We request no Microsoft Graph permissions for it. Not a narrow set: none. Access to an Azure subscription does not come from a consented API permission at all. It comes from an Azure role assignment you make in your own portal, to the built-in Reader role, which grants */read and nothing else. We deliberately do not ask for Cost Management Reader, despite the name suggesting it is the read-only one for cost, because its action list contains the wildcard Microsoft.Support/*, which permits support-ticket creation. Nothing the collector holds can write to your subscription, and revocation is yours alone: the customer removes the role assignment in their own portal, without contacting ITSailor. Sufficiency was settled on 2026-08-15 by running every read path the collector needs as a principal holding that role and nothing else. The same statement is published, from the same source, at our scope inventory.

What it reads. Cost Management figures for a closed month, cost recommendations Microsoft itself computed, your consumption budgets, your policy assignments, and an inventory of resource types, counts, sizes and regions. Every Cost Management call carries a header identifying our collector to Microsoft, so the read is rate-limited in its own bucket rather than sharing yours. That header carries no data about you.

What it keeps, and why we do not expect any of it to be personal data. The inventory returns counts, sizes, regions and resource types. It never returns or stores a resource id, a resource name, a resource-group name, a subscription display name or a tag value, which is the field an Azure estate is most likely to have a person's name in. Budget notification recipients are read and never retained: the pack records only whether anyone is notified at all. Those rules are held by the type, by a schema that rejects an unknown field at write time, and by a scan of the finished pack, not by a convention. On that basis a pack is expected to contain no personal data, and we say “expected” rather than “cannot” because the guarantee is about what we retain, not about what Azure might one day return in a field we already refuse to keep.

What is personal data, or can be. The portal account of the person who connects the subscription, which is covered by section 01 and not by this block. Your Azure directory (tenant) id and subscription id, which identify an organisation rather than a person, but which identify a sole trader as directly as a name would. Stored beside them is an encrypted envelope holding our own application credential for your directory, under a key used for this product alone. It is not your password and not a user token, and nothing from inside your estate is in it.

How long a pack lives. One pack per connected subscription per attested month. No period is fixed in advance, so the criterion is stated instead (Article 13(2)(a)): the packs are the record the product exists to produce, so they stay readable for as long as your subscription with us does, and we delete them on request under section 06. Disconnecting in the portal stops any further read. Removing the role assignment in your own Azure portal is a separate click, and it is the one that revokes our access rather than pausing it.

The free Azure cost review is not this. At our free cost review, a Cost Management export you already have is parsed in your own browser. The file is never uploaded and never reaches our server; only the aggregate leaves your machine, and only if you ask for the report by email. One row of that file carries the subscription identifier, the full resource id, the resource group name, the resource name and every tag value. It is the densest identifier payload Azure produces, which is exactly why we decided not to receive it.

Google API Services User Data Policy: Limited Use

ITSailor's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We use Google Workspace data only to provide and improve the SaaS Auditor features you have authorised. We do not transfer it except as necessary to provide those features or as required by law, we do not use it for advertising, and we do not allow humans to read it except with your consent, for security or to comply with applicable law, or where the data has been aggregated and de-identified.

Deletion and complaints

As the controller, you or your administrator may ask us to delete any SaaS Auditor data we hold for your tenant by emailing dsr@itsailor.io; we action verified deletion requests within the timelines in section 06. Our lead supervisory authority for this processing is the Information and Data Protection Commissioner of Malta (IDPC), and you may also lodge a complaint with the supervisory authority in your own EU/EEA Member State (GDPR Article 77).

Material changes to this Policy will be announced by email at least 30 days before they take effect to all active customers, and posted on this page with a revised effective date. Older versions are available on request.

• Data Subject Rights requests (access, rectification, erasure, portability, objection, restriction, withdraw consent): dsr@itsailor.io
• General privacy questions: privacy@itsailor.io
• Legal: legal@itsailor.io
• General contact: hello@itsailor.io

We have not appointed a formal Data Protection Officer under Article 37 - our scale and processing categories do not require one. If a DPO is appointed in the future, contact details will be added to this section.

Postal: Michal Jatczak T/A ITSailor, Level 1, Unit 60, Door No 63, Connecticlub Business Center, Triq Il-Ballut (Zona Industrijali, Mosta), MST 4001, Mosta, Malta.