Trust Center | ITSailor

Identity and registration

ITSailor is a brand of Michal Jatczak, sole trader registered in Malta · VAT MT32760411 · DUNS 507601021.

Check MT32760411 on the EU VIES register

Partner status

Michal Jatczak T/A ITSailor holds Microsoft Authorized Partner status, Partner Location Account 7113951, Malta partner location.

Verify on the Microsoft partner directory

Commercial route: the Pax8 marketplace, a CSP Indirect Reseller path for Microsoft 365, Azure, backup, and security licensing.

Data protection

The product database, uploads and backups run on Hetzner in Falkenstein, Germany, and serverless functions execute in Vercel's Frankfurt region (fra1). Where a sub-processor operates outside the EEA, ITSailor relies first on the EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795) for sub-processors self-certified under it, and on the European Commission's Standard Contractual Clauses as a standing fallback.

Read the full Privacy Policy

When you connect a Microsoft 365 or Google Workspace tenant to one of the diagnostic tools, every Microsoft permission requested is a Microsoft read permission. One of the three Google Workspace permissions has no read-only variant, because Google publishes none, so it grants more than we use: the permission page says which one, what it permits, and the two things we read with it.

HELMGATE is the exception, and it is what HELMGATE is for. It is a separate application, consented to separately, and it holds four Microsoft permissions that change a tenant: ending sign-in sessions, blocking sign-in, removing a standard group membership, and changing a licence. None of them can reset a password or an authentication method, none can touch a privileged role, and nothing under any of them runs until a second named person approves that specific action. This sentence used to be an absolute in the other direction, and it stopped being true the day the write connector shipped.

The exact scopes, why each one is requested, what is stored, and how to remove access are listed on one page, generated from the code that makes the request so it stays in sync.

See what each connector requests and why

Recipients

Every party that receives personal data from us, condensed from the Privacy Policy. Most are sub-processors, acting on our documented instruction. Some are not, and their rows open by saying so: they decide for themselves what they do with what reaches them. The policy is the authoritative source and is updated first when this list changes.

Recipients: party, role and purpose, and jurisdiction
Processor	Purpose	Jurisdiction
Stripe Payments Europe Ltd.	Our processor for executing payments, subscription charges and refunds on our instruction. Independent controller for fraud prevention, financial and security risk, AML and KYC obligations, and developing its own products	Ireland (EEA). Processing: Ireland, inside the EEA, with routing to Stripe group entities outside the EEA. Transfers: 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	United States. Processing: United States, outside the EEA. Transfers: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
Upstash, Inc.	Managed storage for newsletter and rate-limit state	United States. Processing: United States, outside the EEA. Transfers: Data processing addendum and the Standard Contractual Clauses (EU) 2021/914. No framework listing is claimed.
Hetzner Online GmbH	Production server hosting and backups	Germany (EEA). Processing: Falkenstein, Germany, inside the EEA. Transfers: None needed. The processing does not leave the EEA.
Cloudflare, Inc.	DNS, CDN, and Zero Trust Tunnel	United States. Processing: A global edge network outside the EEA; EU traffic is served from EU edge nodes. Transfers: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
Vercel, Inc.	Frontend hosting and edge logs	United States. Processing: 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. Transfers: EU-US Data Privacy Framework, with the Standard Contractual Clauses (EU) 2021/914 in place regardless.
Plausible Insights OÜ	Cookie-free website and conversion analytics	Estonia (EEA). Processing: Inside the EEA. Transfers: None needed. The processing does not leave the EEA.
GitHub, Inc.	Private repository hosting and tool authentication	United States. Processing: United States, outside the EEA. Transfers: 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)	SaaS Auditor briefs from aggregate figures, contract-document extraction, internal Ops Log drafting	Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Processing: Outside the EEA. Transfers: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
OpenAI (API)	Free-tool diagnostic report and the Tenant Monitor report	Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Processing: Outside the EEA. Transfers: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
Cal.com	Scheduling for discovery calls, demos and paid workshop sessions	Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Processing: Outside the EEA. Transfers: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
DocRaptor	Rendering purchased eBook PDFs, which carry the buyer email in the licence line	Not verified. This row names the service rather than a contracting entity; ask us and we will tell you which entity we contract with. Processing: Outside the EEA. Transfers: Standard Contractual Clauses (EU) 2021/914 alone. No framework listing is claimed, because none has been verified.
Google LLC (reCAPTCHA)	Not our sub-processor. The reCAPTCHA script loads into your browser on our contact and scan-request forms, so your browser sends device, network and interaction data to Google directly. We are a controller for that collection and transmission (CJEU C-40/17 Fashion ID); Google determines what it does with the data afterwards	United States. Processing: Outside the EEA. The data goes from your browser to Google and does not pass through our systems. Transfers: No transfer instrument of ours covers this path, and we claim none. Whether one is required is with counsel.
Microsoft Ireland Operations Limited	Not our sub-processor. Licensor and platform operator for Microsoft 365 bought through us via Pax8. Microsoft processes your tenant content as YOUR processor under its Data Protection Addendum, on your instructions and not ours	Ireland (EEA). Processing: Your own tenant, under the agreement you hold with Microsoft. The contracting entity is inside the EEA. Transfers: 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.	Not our sub-processor. Wholesale supplier and provisioning rail for Microsoft licensing. Pax8 receives your order data as an independent controller in its own right to fulfil the wholesale order; your tenant data does not reach it	Netherlands (EEA), for the EU wholesale operation. Processing: Netherlands, inside the EEA. Transfers: Not ours to state. Pax8 receives the order data as an independent controller, so its own position governs that processing.

Read the full sub-processor disclosure

Data residency

Personal data at rest is held inside the EU/EEA: the product database, uploads and backups on Hetzner in Falkenstein, Germany, and our own business records in Malta. Serverless functions execute in Vercel's Frankfurt region (fra1). Short-lived state leaves the EEA: sign-in state for five minutes and a free-scan result for ten are held by Upstash in the United States, and email delivery, the model that drafts free-tool reports, and code hosting also run outside the EEA. The sub-processor register above names the location of each one.

Security and resilience

The technical and organisational measures required by Article 32 of the GDPR, with the status each one actually has. This is an extract of the internal record of processing activities, which was verified against the running code on 8 August 2026. Nothing is upgraded on the way out: a measure that is pending in the record is pending here, and a measure that is absent is listed as absent rather than left out.

Read the status column literally. In place means implemented and running on the date above. Pending means written, or decided, and not yet running, so it is not something to rely on today. Not in place means it is not implemented and no commitment is made by listing it. Two rows can be checked from outside without asking us, and both say so. For the rest the evidence is code in a repository that is not public, so treat them as terms we hold in writing rather than as measurements you have seen.

Encryption and identifiers

Encryption and identifiers: measure, what is actually the case, and status
Measure	What is actually the case	Status
Transport encryptionGDPR Art. 32(1)(a)	All public traffic is served over HTTPS and every response carries a strict transport security header, subdomains included, with preload set, so a browser that has seen this site once will not accept a downgrade. The lifetime differs by hostname and the difference is stated rather than averaged: two years on this website, one year on the API and the automation service, where the setting belongs to the network provider in front of them. You can check the part you are looking at: read the response headers of the page you are on.	in place
Minimum TLS versionGDPR Art. 32(1)(a)	TLS 1.2 is the floor on every public hostname, measured on 20 September 2026 rather than assumed. Each of the three was offered TLS 1.0 and TLS 1.1 and each refused the handshake at the protocol level; TLS 1.2 and TLS 1.3 were accepted. This is the second row on the page you can check yourself, and it needs a tool rather than a browser: offer an old protocol version with an SSL client and read what comes back. Two limits travel with it. ITSailor terminates no TLS on the public path, so the floor belongs to the hosting providers and they can move it without notice and without telling us, which is why this row is re-measured at every quarterly recovery drill and carries the date it was last read. And a floor is not a cipher policy: this says which protocol versions are refused, not which ciphers are preferred.	in placemeasured 20 September 2026, and the setting belongs to the providers
Tenant credentials held for recurring monitoringGDPR Art. 32(1)(a)	A Microsoft refresh token kept so a subscribed scan can repeat is encrypted with AES-256-GCM in a versioned envelope carrying its own authentication tag, under a key held outside the database. If the encryption fails, or the key is absent, the token is not stored at all. There is no plaintext fallback path.	in place
Identifiers before they reach a logGDPR Art. 32(1)(a)	Directory identities are replaced with a one way SHA-256 digest before anything is written to a log, and there is no reverse function. The honest limit: the digest is computed without a secret key, so it is pseudonymisation under Article 4(5) and not anonymisation. A party holding an identifier can test it against the digest, and pseudonymised log data remains personal data in our hands.	in place
Off-site backups encrypted at restGDPR Art. 32(1)(a), DORA Art. 12(2)	Deployed 2026-08-11. The nightly bundle is encrypted before it leaves the host, to two recipients, and neither private half exists on that host: one is in a password manager and one is on an offline drive. The environment files no longer travel inside the bundle at all; a manifest of variable names replaces them. That manifest was tested for the first time on 20 September 2026 and found incomplete: the automation stack loads a second environment file, the manifest listed three fixed paths, and the rebuild could not start that stack from the bundle alone. Fixed the same day. The manifest is now derived from what the compose files actually read, and a section whose parse comes up short of the assignments in the source file is stamped incomplete rather than presented as the full list. The honest limit: the bundle still carries database dumps, so it holds stored credentials as ciphertext and password hashes. What a stolen bundle does not yield is a plaintext credential or the key to that ciphertext.	in place
Encryption at rest of the production database volumeGDPR Art. 32(1)(a)	Not implemented. The production databases run in containers on a single server with no full disk or volume encryption. ITSailor does not claim database encryption at rest, and a physical or hypervisor level compromise is not mitigated by it.	not in place

Platform, change control and detection

Platform, change control and detection: measure, what is actually the case, and status
Measure	What is actually the case	Status
Network exposureGDPR Art. 32(1)(b), NIS2 Art. 21(2)(i)	Read off the live host on 21 September 2026 rather than carried from a provisioning note. The host firewall admits three ports, and two of them go nowhere: nothing listens on 80 or 443. Every application is bound to loopback and published through an outbound-only tunnel, so none of them has an inbound port at all. SSH is the only service on this machine that accepts traffic from the internet. You can check the shape of that from outside: the service ports are dropped, and 80 and 443 refuse the connection rather than timing out, which is what a firewall that admits a port with nothing behind it looks like.	in place
Remote administrative accessGDPR Art. 32(1)(b), NIS2 Art. 21(2)(i)	Public key SSH only. Root login and password authentication are both disabled, administration runs through a named non-root account, and repeated failures from one source are banned automatically. Two things this row owes a reader who checks. Password authentication was disabled on 21 September 2026 and this row claimed it before that date, having described a step that was never applied; it was found by reading the running configuration rather than the document that described it. And the proof is an external one, because the configuration file is not evidence that the service is enforcing it: an anonymous client is now told the only method is a public key.	in place
PatchingGDPR Art. 32(1)(b), NIS2 Art. 21(2)(e)	Operating system security updates are applied automatically on the production host, verified on 21 September 2026 as a mechanism that runs rather than a service that is enabled: it logs several times a day and had nothing outstanding that it is permitted to install. The honest limit is the whole of what is open. Installing is automatic and restarting is not, so a kernel fix sits installed and not running until someone reboots, and that condition has recurred since June. The two application images are pinned to exact versions rather than a moving tag, so a rebuild reproduces the running versions.	in place
Browser side hardeningGDPR Art. 32(1)(b)	Every response from this website carries a content security policy, a nosniff header, a frame ancestor restriction, a referrer policy and a permissions policy denying camera, microphone, geolocation and topics. Read the scope exactly: this is the public website. The API carries a content security policy of its own and a nosniff header; the automation service, which is an authenticated administrative surface and not a customer one, carries the nosniff header alone. The honest limit: the website policy is a static one, so its script directive permits inline script. It stops script loading from an unlisted host, exfiltration to an origin outside the connect list, base tag hijack, plugin embeds and third party framing. It is not the defence against injected inline script; that defence is sanitisation at the point untrusted HTML is rendered.	in place
Abuse and brute force controlGDPR Art. 32(1)(b)	Sliding window rate limits on sign-in, password reset, public form submission, the consent audit, checkout and document rendering. The honest limit: when the limit store is unreachable the limiter degrades to a per instance bucket rather than refusing traffic, so losing it weakens protection instead of closing the purchase path.	in place
Change controlGDPR Art. 32(1)(b), NIS2 Art. 21(2)(e)	Every change to the production frontend goes through a pull request and the automated gate below runs on it. Stated accurately: that gate reports, it does not block. There is no repository ruleset and no code owner rule, so the convention rests on one person observing it, and this project has one recorded merge with a red gate that broke the main branch.	in placeas a convention, not as an enforced control
Availability monitoringGDPR Art. 32(1)(b), NIS2 Art. 21(2)(b)	External monitors poll four services every five minutes and alert by email: the API health endpoint, the customer portal, this website and the automation service. The monitoring provider publishes the result on a public status page. This row said it covered the API alone until 21 September 2026, which understated it.	in place
Availability service levelGDPR Art. 32(1)(b)	None is offered and none is committed, and nothing here changes that. What exists is a measurement rather than a promise: the monitoring provider publishes an uptime ratio per service on a public status page, over its own window. Read it as an observation of what happened, not as a level anyone has agreed to meet. ITSailor publishes no derived figure of its own. This row said no percentage had been measured, so none was published; the second half was untrue, and it was corrected on 21 September 2026 rather than left to be found.	not in place
Security event detection and alertingGDPR Art. 32(1)(b), NIS2 Art. 21(2)(b)	No centralised log aggregation, no security information and event management system, and no alerting on security events. Alerting exists for availability only, so detection of a security event depends on someone looking.	not in place
Backup state alertingGDPR Art. 32(1)(b), DORA Art. 12(2)	Deployed 2026-08-28. An external monitor holds the backup schedule and a grace window. The run reports its start, its success, and its failure on every route out of the script, and a run that never happens at all breaches the grace window and raises the same alarm. That last case is the one this control exists for: a backup that stopped running is otherwise indistinguishable from one that ran, until the day it is needed. Proved on the day rather than assumed: a forced failure raised the alarm and the next clean run cleared it. Two defects surfaced while it was being built, and both are the reason a success signal now means something. A failed off-site verification used to record the failure and then exit successfully; it fails the run now. And an archive step could ship an empty bundle when its source directory was absent, because the container runtime creates a missing source rather than refusing; the sources are proved present before they are read, and every artefact is compared against the last run that verified off-site. Three limits, stated because none of them is closed by this row. The alert is email to one person, which is the concentration described further down this page and not a second risk. It reports on backup runs and not on security events, so the detection row above is unchanged. And the credential the run uses to report health sits on the production host, so a compromise of that host could forge a healthy signal; what survives that compromise is the copy the host cannot delete, not this.	in place
Server side loggingGDPR Art. 32(1)(b)	Structured single line logging with a stable event name exists through a shared module, and the migration to it is partial: most server logging is still raw console output. The count and the method behind that word are in the record, measured once, and are deliberately not restated here.	partial
Log integrityGDPR Art. 32(1)(b)	ITSailor does not operate write once or tamper evident log storage.	not in place

Backup and restore

Backup and restore: measure, what is actually the case, and status
Measure	What is actually the case	Status
Automated twice daily backupGDPR Art. 32(1)(c), DORA Art. 12(1)(a)	Scheduled jobs at 03:00 and 15:00 Malta time dump both production databases, archive the uploads, the extensions and the automation data volume, and ship the bundle off-site to a storage box in Falkenstein, Germany. The second run was added on 14 September 2026; before that the cycle was daily. The host also carries a server backup product from the hosting provider, which is crash consistent only and is a second copy rather than the copy. On 20 September 2026 a bundle this schedule produced was restored onto a replacement machine and reconciled against the source, so the schedule is now proved by restoration rather than only by its own run log.	in place
Geographic separation of the off-site copyGDPR Art. 32(1)(c), DORA Art. 12(2)	The only off-site copy sits in the same location as the production host. There is no second region and no second provider, so a regional loss takes both. This is a cost decision on an estate that costs about twenty euro a month, and it is written down rather than left to be inferred.	not in place
Documented restore procedureGDPR Art. 32(1)(c), DORA Art. 12(1)(b)	A restore script exists and the procedure is written step by step, from stopping the application containers through restoring both databases, the uploads and the automation volume, to polling both health endpoints until they return healthy. Exercised on a replacement machine on 20 September 2026, which found two defects in it. The backup bundle did not list every environment file the automation stack loads, so that stack could not be started from the bundle alone; and the restore script checked its preconditions while running rather than before, so a missing container surfaced partway through instead of at the start. Both were fixed the same day. The script now also refuses to run until the operator types the name of the machine that is about to be overwritten, which is a harder question than yes or no and the only one that catches the wrong terminal window.	in place
A copy the production host cannot deleteGDPR Art. 32(1)(c), DORA Art. 12(3)	Provider side snapshots were enabled on 2026-08-11, on a daily schedule, and the production host holds no credential that can create, alter or delete one. Tested rather than assumed, in three parts on that date: the backup identity CAN delete a live off-site file, because the storage product still offers no write without delete permission; it CANNOT touch snapshot history, which returns a read only filesystem error; and a file it had deleted was recovered from a snapshot with a matching digest. Deletion by this host is therefore survivable. One limit, and one correction this page owes its own reader. The limit: the recovery window is bounded by the number of snapshot slots. The correction: this row used to say the first scheduled snapshot had not yet run, so that depth did not exist. It exists now. A backup run on 2026-08-28 read ten automatic snapshots from the provider, and every run reads that count, so a schedule that quietly stops producing shows up in the log of the next run instead of at the next restore.	in place
Recovery point objectiveGDPR Art. 32(1)(c), DORA Art. 12(6)	None is committed. The cycle runs twice a day, so the architecture bounds the loss at twelve hours; before 14 September 2026 that bound was twenty-four. Measured once: a rebuild from an off-site bundle on 20 September 2026 lost ten hours of database change, which came to 1,200 activity rows out of 228,609 and no files at all. Read that as an observation taken on one date under one failure mode. It is a bound produced by the architecture and a figure produced by a drill, and neither is an objective anyone has agreed to meet.	not in place
Recovery time objectiveGDPR Art. 32(1)(c), DORA Art. 12(6)	None is committed. A rebuild from backup onto a fresh machine was performed for the first time on 20 September 2026 and took one hour and twenty-five minutes, against an internal target of eight hours that had been derived from a criticality tier. Two bounds travel with that figure and a reader should not separate them from it. The public hostname was deliberately left pointing at production for the whole exercise, so no name service or tunnel cutover time is included. And the run finished only because a file missing from the backup bundle could be read off the production host, which in the scenario under test does not exist. The internal target was left at eight hours rather than tightened to match the measurement, because one sample under one failure mode is evidence that a target is reachable and not grounds for promising it.	not in place

Testing, assurance and vulnerability handling

Testing, assurance and vulnerability handling: measure, what is actually the case, and status
Measure	What is actually the case	Status
Automated gate on every changeGDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)	Every push and every pull request runs the linter, a full type check, the complete test suite, a production build, a prerender presence check, a bundle size budget, a software bill of materials and a committed secret guard. Stated accurately: it reports, it does not block. See the change control row above.	in placeas a reporting gate
Tested controls, not only tested codeGDPR Art. 32(1)(d)	Three tests in that suite check controls rather than features. Connector scope parity asserts that the permissions published on the connector page are the same set each connector actually requests, so a permission cannot be added without being published. Recipient parity fails when the published sub-processor list and the Privacy Policy disagree. A claim gate constrains what this site may assert. You can check the first one: the permission page is public and is generated from the array the connectors send.	in place
Dependency inventoryGDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)	Continuous integration produces a CycloneDX software bill of materials on every run. Its scope is the frontend package tree, and that scope is part of the claim: the pinned container images running on the production host are not in it.	in placefrontend package tree only
Dependency vulnerability scanningGDPR Art. 32(1)(d), NIS2 Art. 21(2)(e)	Automated from 2026-08-28. A dependency update service opens grouped pull requests for the application tree, the operational scripts, the actions the pipeline itself runs and the pinned container images, with major versions held back so they arrive one at a time. A weekly workflow audits the dependency tree against two independent advisory databases. Which one stops a release is stated rather than blurred: the package registry feed blocks the pipeline on a high or critical finding in the tree that reaches a user, and the second database runs beside it as a cross-check and reports. The two do not hold the same set of advisories, so a disagreement between them is a thing to read rather than a thing to fail a deploy on. The same workflow scans container images, which no package tool can see and which the inventory row above says plainly are not covered by the bill of materials. Its scope is stated rather than implied, because the six images it covers are not equally well evidenced. Three of them, the content API and its database and cache, are pinned in the repository, and by a written convention those are the versions production runs. The other three, the automation service and its own database and the document renderer, are configured on the production host, so their versions are held here as a transcribed list taken from a verified server state of June 2026. A clean result for those three proves the recorded version is clean rather than that the running one is, and nothing reconciles that list against the host automatically. The weekly schedule is the load bearing part rather than the check that runs on changes: an advisory published against code nobody edited is invisible to a scan that only runs on edits, and that is how every finding below arrived. What the first run found is published here, because it is the evidence that this control does something. Eighteen vulnerable packages, one of them critical, and the critical one was in the authentication library. Five of the eighteen were held open by version pins held in this repository rather than by any missing upstream fix, so the remedies existed and were being pinned out. All eighteen are closed and the audit now returns zero. Those figures are ITSailor own record of its own run; nothing on this page makes them checkable from outside. Three limits. There is still no static analysis of the code ITSailor writes: that needs a paid add-on this business does not hold, so this row covers dependencies and not application source. Findings in upstream container images report rather than block, because a fix there waits on its publisher and a red gate would stop every unrelated deploy. And the development only tree reports rather than blocks, which is a real split and not a softening: of the packages still outstanding after the first pass, seven reached a user and six existed only in a linter and a component tool.	in place
Restore provedGDPR Art. 32(1)(c), DORA Art. 12(2)	Two dated events. On 11 June 2026 a full restore ran end to end on the production host and both services returned healthy; read that one for what it is, a database restore onto a healthy running host, and not a rebuild from nothing. On 20 September 2026 the rebuild from nothing was done: a throwaway machine, the whole estate reconstructed from a single encrypted off-site bundle, both services healthy, and the result reconciled against the source by row count and by file count. Production was not modified at any point during the second.	in placetwo dated events, one of them a rebuild from nothing
Recurring restore drillGDPR Art. 32(1)(d), DORA Art. 11(6)	The first drill ran on 20 September 2026, nine days after the date the programme had set for it. It rebuilt the estate from nothing onto an isolated machine, measured a recovery time and a recovery point, and raised fourteen issues, three of them critical, each with an owner and a date. One of those would have stopped a real recovery outright, and it was fixed the same day. The third critical finding was not produced by the drill but by reading a figure the drill had made worth reading, hours after the clock stopped. This row is partial rather than in place for one reason: one drill is not a cadence. The programme is quarterly on paper, the second instance is due 11 December 2026, and until that one runs what exists is a single dated exercise and not a rhythm.	partial
Penetration testingGDPR Art. 32(1)(d)	None has ever been performed and none is claimed. No report exists, so none is offered, summarised or held behind a request form.	not in place
Periodic access reviewGDPR Art. 32(1)(d), NIS2 Art. 21(2)(i)	There is no documented periodic review of which provider console holds which access. Access accumulates by default.	not in place
Vulnerability reports from outsideNIS2 Art. 21(2)(e)	A security contact is published under RFC 9116 at the well known path, and the scope, the safe harbour and what is out of scope are on this page. Before this existed there was no reporting channel at all.	in place

People, and the concentration that comes with one of them

People, and the concentration that comes with one of them: measure, what is actually the case, and status
Measure	What is actually the case	Status
People with access to customer personal dataGDPR Art. 32(1)(b), DORA Art. 29	One. There are no employees, and no agency worker or sub-contractor holds standing access to production systems or to customer data. Access is not granted to anyone; it is held by one person or it does not exist.	in place
Separation of dutiesGDPR Art. 32(1)(b), DORA Art. 29	Not achievable in a one person business, and not claimed. The author, the reviewer, the approver and the deployer of a change are the same person, which is why the automated gate above is described as the only independent check standing between a change and production.	not in placestructural, and disclosed
A second operatorDORA Art. 29, NIS2 Art. 21(2)(d)	There is none. Availability of the service depends on one person, and a restore additionally requires the password manager held by that same person. That has been true since the backup was encrypted on 11 August 2026, and the rebuild of 20 September 2026 proved it by depending on it: the private half of the key was fetched from that password manager for the length of the exercise and destroyed afterwards. This is the concentration risk a customer has to record and decide about; it is not a defect ITSailor can close by writing something down.	not in placestructural, and disclosed

What ITSailor does not hold

No ISO/IEC 27001 certification.
No SOC 2 attestation of any type.
No Cyber Essentials or equivalent scheme certificate.
No cloud security alliance registry entry.
No penetration test report.

The section above is structured against Article 32(1)(a) to (d) of Regulation (EU) 2016/679 so you can map it onto your own obligations under Regulation (EU) 2022/2554 and Directive (EU) 2022/2555. Those are reference points for your register. They are not claims that ITSailor has been certified, assessed or audited against any of them, and ITSailor is not itself a financial entity within the meaning of Regulation (EU) 2022/2554. Where your procurement process requires a certificate, ITSailor cannot supply one. What it can supply is an extract of this record, the recipient register below, and the audit and information rights in the data processing agreement.

Security contact

Report a vulnerability to security@itsailor.io. The same details are published in machine-readable form at /.well-known/security.txt under RFC 9116. Reports are read in English or Polish.

One person reads that mailbox, so no response time is committed. Saying it plainly is more useful than a target nobody has measured. If a report needs an acknowledgement by a date, say so in the message and it will be prioritised over everything else.

What you may test

The public website and the publicly reachable endpoints of the ITSailor products, from your own account or your own tenant. Please stay within these limits, because they are what let the safe harbour below mean anything: no denial of service or load testing, no automated scanning that degrades the service for anyone else, no social engineering of the founder or of any provider, no physical testing, and no access to, alteration of or exfiltration of data belonging to another customer. If a proof of concept would require another party's data, stop and describe the path instead.

Out of scope: customer Microsoft 365 and Google Workspace tenants, which are the customer's systems and not ours to authorise testing against, and the infrastructure of the providers listed under Recipients below, which have their own disclosure programmes and are the right place for a finding in their platform.

Safe harbour

Where you follow the limits above, act in good faith, and give ITSailor a reasonable opportunity to fix the issue before disclosing it publicly, ITSailor will not bring or support a legal claim against you in relation to your research. ITSailor cannot waive the rights of a third party, so this covers ITSailor only. There is no bounty, and none is implied.

Data subject rights requests (access, rectification, erasure, portability) go to dsr@itsailor.io, not to the security address. General legal correspondence goes to legal@itsailor.io.

Documents

Data Processing Agreement (DPA): available on request during scoping.

Register of information

DORA Articles 28 to 30 require you to keep a register of information on every ICT third-party arrangement, to assess concentration risk, and to hold an exit strategy. Everything you need from us for that register is below, in one block, written to survive being copied into your own document.

Legal entity                        Michal Jatczak, sole trader registered in Malta
Trading name                        ITSailor
VAT identification                  MT32760411
D-U-N-S                             507601021
Function supported                  ICT consultancy, Microsoft 365 and Azure architecture, security and cost tooling
Position in the chain               Direct provider. Microsoft CSP Indirect Reseller via the Pax8 marketplace
Microsoft Partner Location Account  7113951
Data location                       EU/EEA. Storage on Hetzner, Falkenstein; functions in Vercel Frankfurt (fra1)
Sub-processors                      Listed in full at itsailor.io/trust#sub-processors
Data Processing Agreement           Not signed by default. Available on request during scoping
Exit strategy                       Exit Kit delivered within 24 hours of SOW engagement close. No request required
Exit clause                         itsailor.io/legal/terms#exit-kit
Deliverable ownership               Perpetual royalty-free licence, transferable without approval

Check MT32760411 on the EU VIES register Look up D-U-N-S 507601021 at Dun and Bradstreet

The Exit Kit is delivered within 24 hours of engagement close on a SOW engagement.: It is a term in the contract, not a time anyone has recorded, and it is not something you have to ask for. The pack is the architecture documents, configuration baselines, IaC modules, runbooks and the credentials a competent successor needs to run the estate without us. The 24-hour window covers consulting and implementation engagements under a SOW; the €499 workshop pack runs to a separate 5-business-day deadline, refunded in full if missed.; Terms, section 05
Every deliverable is licensed to you perpetually and transferable to a successor supplier without asking us.: A perpetual, irrevocable, royalty-free licence to the architecture documents, Terraform modules, baselines and runbooks produced for you. No approval to ask for and no clause to negotiate on the way out. Ownership stays with us, the licence runs subject to payment in full, and third-party and open-source components inside a deliverable keep their own licences, all of which section 04 names. Licences bought through us are a different thing again and stay with the vendor, which section 3.4 says in full.; Terms, section 04, licence and ownership

Neither register above takes a prefilled number: both are search forms, so the identifiers are rendered here for you to paste. If a field you need is missing, ask and it will be added to this block rather than answered once by email.