privacy policy.

Version 1.17, 31 August 2026. Questions, requests and corrections: contact@noctovisor.com

1. Who we are

Noctovisor is operated by Noctovisor – Piotr Bogdanowicz, a business registered in Poland.

We have not appointed a data protection officer. Article 37 GDPR makes one mandatory where the core activity is regular and systematic monitoring of individuals on a large scale, or large-scale processing of criminal-offence data. What we monitor is companies; the personal data we handle is incidental attribute data on documents about companies, and we do not profile or score individuals. We reassess this position as the service grows, and will appoint a DPO and notify UODO if it changes.

2. When we are controller and when we are processor

We are the processor for the list of companies a customer sends us, the monitoring criteria they state, the email addresses they nominate, and the alert record we hold for them. The customer is the controller. Our obligations to them are set out in the data processing agreement, not here.

We are the controller for website visitors, enquiries, our own correspondence and billing, and for our selection of public sources and our collection of material from them, because no customer tells us which registers to read.

We do not use a customer's list, criteria or alert history for our own purposes: not for marketing, not for benchmarking, not to train any model. A customer's list is confidential from the moment it is sent, whether or not the sender becomes a customer.

One thing we do count. When somebody marks an alert (looking into it, dealt with, no action needed), we add one to a monthly tally of how often each mark is used, across everybody. That tally holds a month, a mark and a number. No customer, no alert, no company, nothing that can be traced back to anyone or joined to anything. We keep it to see whether our alerts are landing where we set them, and it survives after a customer leaves, because by then there is nothing personal left in it to delete.

3. What we handle

• From people at customers and prospects: work email, and whatever else you choose to tell us (a name, a company, context) in a form or an email. Business contact data.
• What you tell us about an alert: the mark you set on it and anything you write about it, whether you reply to the email or use the comment link it carries. It is kept with the alert it answers and comes back to you in your monthly report. A comment left through a link records no sender: the link identifies the alert, not the person, and we hold no name rather than guess at one.
• Nominated recipients: the addresses a customer tells us to send alerts to.
• The customer's list: the companies the customer asks us to watch (their suppliers, service providers, customers, partners or any other third party) as company names and domains. Nothing else: no contracts, no spend data, no questionnaire responses. Occasionally a list contains a personal name, where a watched business is a sole trader or a customer's own file carries a contact column.
• Material from public sources: court filings, insolvency notices, register entries, sanctions listings, regulatory notices and adverse media. Section 5 covers this in full.
• Website visitors: the request information any web server sees (IP address, user agent, page, timestamp) held by our network provider. No analytics is installed, the page carries no third-party code, and nothing the page itself runs stores anything on your device or reports your visit anywhere. Cloudflare's bot-detection cookie is covered in the cookie notice.
• Billing: company name, address, VAT number, invoices, and the email address of whoever pays. Where you pay by card, Stripe takes the payment on a page it hosts itself, so your card details go to Stripe and never to us. We hold no card number, no expiry date and no security code, only the fact that a payment was made and the last four digits Stripe shows us on the record.

4. Why, and on what legal basis

Polish law requires prior consent for direct marketing by electronic communication and applies that to business recipients too. In the EU we therefore send at most one short message to a work address, asking whether we may send a proposal; it describes no product and is not repeated. An offer follows only if you answer yes. A no, or silence, means we delete your details within thirty days. Outside the EU, where the law of your country allows it (for example CAN-SPAM in the United States), we may write once or twice to your work address about your role; every such message says where we found your address, links this policy, and stops for good when you reply "stop". If you write to us, we reply about what you asked and do not add you to a list.

We do not sell personal data, share it for advertising, or run advertising technology of any kind.

5. Personal data in public registers and court records

What we collect

Company registers name directors and officers. Insolvency filings name administrators. Sanctions listings name designated persons. Enforcement notices name respondents. We carry those names through, because a customer reading an alert needs to know who the record refers to, and stripping the name would make the evidence useless for the regulatory file they are building.

What we do not do: we do not build a record about a person. Our unit of record is the company, and a name is an attribute of a document about a company. We do not enrich, look up home addresses, assemble personal contact details or pull social media. We do not score individuals. We never contact a watched company or anyone at one, and we read nothing we are not lawfully entitled to read. Some public records sit behind a registration or a per-page fee, court dockets in particular, and we pay for those like anyone else.

Why we think this is lawful

Publicly available does not mean unregulated, and we do not treat it that way. It does mean the Article 6(1)(f) balance is favourable here:

• The purpose is concrete. Firms under DORA, NIS2, SEC Regulation S-P, NYDFS Part 500 and CMMC are required to know things about their third parties.
• The processing is necessary for it. You cannot detect that a company filed for insolvency without reading the filing, and the filing names people.
• The data is already published, mostly under a legal duty. A commercial register, an insolvency gazette and an official sanctions list exist in order to be read.
• The impact is narrow. It goes to one customer who already has a lawful reason to look at that company, with a link to the original source, and nowhere else.
• Nothing new is created. We ask nobody anything.

This argument is strongest at the scale we run at today, and it weakens as volume grows. We treat it as something to be revisited by counsel before we scale well beyond design-partner pilots, not as settled.

Adverse media is treated more strictly. A news article is public but not published under a legal duty. We carry a name only where the source names that person in connection with the monitored company, we do not treat a report as established fact, and the alert says what the source actually claims. We do not aggregate coverage into a reputation signal.

This is our own reading rather than advice: whether adverse media about a named individual sits on the same footing as an official sanctions listing is a question for a lawyer, and it is the part of this assessment we expect to revisit first.

Whether we notify the individuals named

Article 14 GDPR normally requires telling someone when their data was obtained from a third party. We obtain these names from registers and courts, not from the people named, so the duty is engaged.

We do not send individual notices. We rely on Article 14(5)(b), disproportionate effort, and discharge the alternative obligation by publishing this policy and our sources page. Our reasons:

• We have no way to reach these people. A register publishes a name, not an email address. Notifying would mean collecting more personal data about someone in order to tell them we hold less.
• Notifying would disclose a customer's commercial position to the party they are assessing, and we do not contact the companies being watched.
• The population is large and changes daily as registers update.
• Against that, the intrusion is limited: register-published facts about a company role, no enrichment, no scoring, no marketing use, one recipient, a link to the source, limited retention.

The exemption is narrow, so these safeguards go with it: data minimised to what the register already published; no profiling of individuals; this policy and the sources page published so anyone can see the kinds of record we read; each source named specifically in the alert rather than as "public registers"; and a written balancing assessment we keep, revisit when we add a source, and make available to the supervisory authority on request.

The rest of what Article 14 asks us to tell you, in one place, because otherwise it is scattered across this document. Who receives it: the one customer monitoring that company, and the providers in section 7, which includes a US language model provider, because drafting the alert means sending it the record and the name in it. How long: we hold the finding for as long as the customer's watch on that company runs, and it goes when their record goes; we do not keep a separate file on you that outlives it. Transfers: section 7 names the mechanisms, and you can have a copy of the clauses by asking at contact@noctovisor.com.

And a direct channel. If your name appears in a public record about a company, email contact@noctovisor.com. You can ask what we hold and where it came from, and you can object under Article 21: where we are the controller we will carry out the balancing exercise ourselves and tell you the outcome either way. Where the record sits inside a customer's watch, that customer is the controller: we pass your request to them, help them answer it, and tell you we have done so. We do not name them to you unless they agree or the law requires it, because who is assessing whom is their commercial position, not ours to disclose. No form, no article citation, no proof required.

Criminal offences and allegations

Sanctions and adverse-media screening can surface material about alleged or established offences (Article 10 data). This processing is narrow by design: we run no standalone search or screening query about a named individual, we do not aggregate adverse media about a person, and we do not cross-reference a name across unrelated companies. Any personal detail that reaches an alert already appeared in a source about the monitored company, carried through as found. This limit is stated publicly at noctovisor.com/sources.html.

As an additional safeguard, the customer confirms in the data processing agreement that they hold their own lawful basis for receiving this category of data, typically an AML, KYC or sanctions obligation under their own regulatory regime. If a customer cannot give that confirmation, we narrow what we watch for them rather than sending it anyway.

6. Automated processing

Each source has its own checking interval, set to how often that source actually changes: there is no point reading a register daily if it updates weekly, and the fastest-moving sources are checked every day. Entity matching, deduplication and comparison against the customer's stated criteria are automated. Alert text is drafted and translated by large language models, and a second automated check reads each claim back against its source before the alert is sent. Which confirmed items reach a customer's weekly log is decided automatically against that customer's own stated criteria, and a person reads every alert and every weekly log before it is sent.

This is not automated decision-making under Article 22. An alert is information, not a determination: not legal, financial or compliance advice, and not a verdict on the company or on anyone named in the record. We do not decide, recommend, rank, score or rate. Every decision (whether to keep the relationship, escalate, file or do nothing) is made by a person on the customer's side, who can open the source document. That holds where a watched business is a sole trader, because what we pass on is still a published record rather than an assessment we generated.

We will not introduce a risk score or rating for the companies we watch without revisiting this section first.

We also state, here and in the alerts, that alert text is machine-drafted and machine-translated.

7. Who else is involved, and where

We keep our supplier base deliberately small. The sub-processor list is the dated, authoritative version. In outline:

• Hosting: one virtual private server rented from OVH, contracted through OVH's Polish entity; the machine is physically in Canada. Both the database and the monitoring pipeline run on it.
• Cloudflare provides nameservers, the reverse proxy and website hosting, and carries the connection to the comment page an alert links to. A comment you leave passes through its network on the way to our server, in transit, and is not stored there. No customer list, finding or alert passes through it.
• Anthropic, xAI, OpenAI and Google draft and translate alert text and run the automated check against the source, in the United States. Section 8 explains what reaches them.
• Our contact mailbox is hosted by Google (Workspace) with the data region set to Europe. A list sent by email arrives and is held in the EU, so no transfer arises before anything reaches Canada. A list submitted through the website form reaches the same mailbox relayed by Resend (below), which retains the message for 30 days under its terms. Some service metadata sits outside the data region's scope and may be processed in the United States.
• Resend, a US company, sends alert emails from the subdomain alerts.noctovisor.com, and relays watch-form submissions to our contact mailbox. A comment left through an alert's link does not pass through it, or through any mailbox: it goes from your browser to our own server and stops there.
• We engage no error monitoring and no log management service. Stripe is engaged for card payment and nothing else: it receives billing details and never your list, your watched companies or your alerts. Our scheduled jobs do send success pings to an uptime service so we notice if one silently stops; those pings carry job names only, never a customer, supplier or any other identifier.

Where your data is processed: Canada and the United States, not the EEA, other than the contact mailbox, held in the EU, and one backup copy in Warsaw, covered in section 9. For Canada we rely on the EU adequacy decision, confirmed in force by the Commission's review of 15 January 2024, supplemented by the standard contractual clauses in Commission Implementing Decision (EU) 2021/914 with our hosting provider. The clauses are there as well as the decision, not instead of it, because the adequacy decision covers organisations subject to PIPEDA and the Canadian capacity we use sits in Quebec, whose provincial regime does not hold adequacy in its own right. For US providers we rely on those same clauses, with EU–US Data Privacy Framework certification as additional cover where a provider holds it.

There is no choice of processing region. If your own rules require EEA-only processing, we cannot meet that today. For a DORA-regulated firm this is a disclosure (the country of processing is a row in your register of information), but some buyers carry residency constraints that non-EEA hosting will not satisfy.

8. What reaches a language model

When we draft an alert, translate it, or run the automated check of it back against its source, that content goes to Anthropic, xAI, OpenAI or Google as a prompt. It includes the watched company's name, and where the underlying public record names an individual and that name is part of the event, the name and the record's facts go too. The check sends the source material itself, which is the point of it. At onboarding, a customer's list is processed by Anthropic agents; after that, our own model requests carry one company at a time and never the customer's name, address or list.

All four providers' terms exclude training on submitted content. All four delete API inputs and outputs within 30 days (three by default, and Google because we set its log-retention window below that rather than leave its 55-day default) so a copy of alert content exists outside our systems for up to that long. Content flagged under a provider's usage policy may be retained longer under that provider's terms. Each provider has some form of zero-retention arrangement, but three of the four grant it only on application and approval, so it is not ours to switch on today. If that changes, this section will say so.

9. How long we keep things

• A list from someone who does not become a customer: everything that is theirs is deleted within 90 days of the end of their watch, or of sending it if they never started one, without them having to ask. That is the list, the matching of the names on it to registered companies, the watch settings, the alerts and reports prepared for them, and their contact details and correspondence record. We cannot delete a list in the middle of the watch it was sent for, which is why the clock runs from the end rather than from the day it arrived. What we read in the public record about the watched companies is ours and is kept under the next bullet; the deletion destroys every link between it and whoever asked.
• What the public record says about a watched company: ours, held as controller (section 5), kept while any customer watches the company and for up to three years after the last watch on it ends, then deleted on schedule. It is the same reading whether one customer watches the company or twenty, which is why it does not belong to any one of them. Where the watched supplier is a business run by an individual, such as a sole trader, we do not keep it: the material about them is deleted with the watch that caused it, unless another customer independently watches them.
• Enquiries that lead nowhere: kept while the conversation is live and a short period after.
• A customer's record during a subscription: kept while the subscription runs, because it is the evidence they are paying us to hold. Customers can export the whole record at any time, and we suggest doing so quarterly so it lives in a file they control. Exports are prepared and sent from our contact mailbox, not through the alert delivery provider (section 7), which never handles an export.
• After a subscription ends: governed by the data processing agreement.
• Alert content at a model provider: up to 30 days (section 8).
• Alert content and website form submissions at our email delivery provider: 30 days after sending, under Resend's published data retention terms (verified 30 July 2026, re-checked 13 August 2026).
• Invoices and tax records: the statutory period. Under art. 86 of the Polish Tax Ordinance these are kept until the tax limitation period expires: five years from the end of the year in which the payment deadline fell. A deletion request cannot override this.
• Backups: held in Canada, plus a second copy on our own encrypted hardware in Warsaw. They run daily and are kept for 30 days, so a record deleted from the live system is finally gone once it has aged out of both, at most 30 days later. The Canadian copy leaves the EEA; the Warsaw one does not.

10. Your rights

If we are the controller you have the rights below. If we hold your data as a processor for a customer, we will pass your request to them, help them answer it, and tell you we have done so.

Access to your data and a copy of it; correction of data that is wrong; erasure where an Article 17 ground applies; restriction; portability; objection under Article 21 to anything we base on legitimate interests, including everything in section 5; withdrawal of consent at any time; and the right not to be subject to a decision within Article 22, which as explained in section 6 we do not take.

How to exercise them: email contact@noctovisor.com and say what you want. No form, no template, no need to cite an article. We will only ask for identity information if we genuinely cannot tell who you are, and we will ask for the least that will do.

If your name appears in a public record we hold: we can search our records for a name to answer you. That is worth being exact about, because we say elsewhere that we keep no register of individuals and both are true: nothing is indexed by person and we never run a person-first search to produce an alert, but we can search the text we hold when someone asks us to, and we do that only to answer a request like yours or to meet a legal obligation. We will tell you what we hold and which source it came from. We will not tell you which customer it relates to unless they agree or the law requires it. If the underlying register is wrong, the correction has to be made at the source or our copy will be refreshed from it. We will tell you which body to approach and act on our copy once the source is fixed.

How long we take: one month, as Article 12(3) requires, extendable by two further months for complex requests, in which case we will tell you inside the first month.

Complaints: tell us and we will look again. You can also complain to the Polish supervisory authority, whether or not you raise it with us first:

Prezes Urzędu Ochrony Danych Osobowych
ul. Stanisława Moniuszki 1A, 00-014 Warszawa, Poland
uodo.gov.pl

If you are elsewhere in the EEA you may complain to your local authority instead.

11. US privacy law

We are established in Poland and operate on the GDPR footing above. We do not currently meet the thresholds at which the CCPA applies to a business. Where we process personal information for a US customer we will contract as a service provider on the terms California requires. We do not sell personal information or share it for cross-context behavioural advertising.

12. Security

Our security summary is a separate document. Three things belong here because they bear on personal data:

• We hold no certification today. No ISO 27001, no SOC 2. We are working toward ISO 27001, with SOC 2 to follow, and will never imply otherwise.
• There is no Noctovisor user directory. No portal, no login, no dashboard. Alerts land in the customer's own mailbox, so the access controls that apply are the customer's. That removes a category of risk rather than managing it.
• Breaches. Where we are controller we notify UODO as Article 33 requires. Where we are processor we notify the customer without undue delay and in any event within 24 hours of becoming aware, deliberately shorter than their own 72-hour deadline, because that deadline runs from the same event and leaving them three hours of it would be no use. The data processing agreement carries the operative terms.

13. Cookies

The website sets no cookies of its own and runs no analytics. Our cookie notice explains the position and why no consent banner is required today.

14. Children

The service is sold to businesses and is not directed at children. We do not knowingly process the data of anyone under 16.

15. Changes to this policy

The version and date at the top tell you which text you are reading, and we do not change the policy without changing that line. Where a change materially affects how we handle personal data we email customers before it takes effect and keep the previous version available on request. Sub-processor changes are announced as the data processing agreement requires; the sub-processor list is dated so you can see when it last moved.

Version 1.17, 31 August 2026. Contact: contact@noctovisor.com