Noctovisor Noctovisor third-party risk monitoring. start the free watch.

security summary.

Version 1.11, 26 August 2026. Questions: contact@noctovisor.com

Noctovisor is operated by Noctovisor – Piotr Bogdanowicz, registered in Warsaw, Poland. REGON 146596070, EU VAT ID PL5262736443, D-U-N-S® Number 427695885.

Start with what there is to steal

Vendor security review usually assumes the vendor holds something dangerous: credentials into your systems, an agent on your endpoints, your contracts, your spend, your users. Noctovisor holds none of that, by design.

What we hold:

  • Company names and domains, as you sent them.
  • The public legal-entity identifiers we matched those companies to.
  • Public-source findings about those companies: filings, register entries, sanctions listings, regulatory notices, press reports. All published elsewhere already.
  • Your work email, your company name, and the addresses you nominate for alerts.

What we do not hold:

  • No contracts and no contract terms.
  • No spend, pricing or commercial data.
  • No questionnaire responses, because we never ask the companies you watch for anything.
  • No credentials, API keys or tokens into your systems. There is no integration to grant.
  • No network access to you. No VPN, no site-to-site link.
  • No software installed anywhere on your estate. Nothing to patch, nothing to remove.
  • No user accounts, because there is no portal and no login. No Noctovisor password to phish, no session to hijack, no user directory to breach, nobody to offboard when someone leaves your team.

One page of ours does take input from a browser, and it is worth describing rather than leaving you to find it. Each alert carries a link to a page for answering that alert: three buttons, a text box, and the alert's reference at the top. It sets no cookie and holds no session, so there is still nothing to log into and nothing to offboard.

What that page is allowed to reach is the part we would want to read if we were you. It runs as its own database identity, granted exactly four things: read a link, write an answer, read which mark currently stands, and add to an anonymous counter. It cannot read your list, an alert, a company, or what anybody else wrote. Cannot, rather than does not: the database refuses it, and our deploy check asserts that refusal every time, column by column, in both directions. It holds no credential for anything else, because the process drops every variable it was not explicitly given before it starts.

It also opened no port. The page is reached through an outbound tunnel the server dials, so the machine that holds your data still listens for nothing from the internet. That is checked from outside, not taken on trust.

The limit: the link identifies the alert, not the person. Anyone your colleague forwards it to can answer that alert, and the record says the answer arrived that way and names no sender, because we hold no name rather than guess at one. Nothing can be deleted through it: a changed answer is a new dated line, and the old one stays.

So the worst case, if every system we run were fully compromised, is that an attacker gets a list of company names, their domains, some public register identifiers and some business email addresses. That still matters: your list is your concentration risk written down, and it is confidential from the moment it arrives whether or not you become a customer. But it is not a breach that reaches into your environment, moves laterally, encrypts anything of yours or exposes a single credential. There is no path from Noctovisor into your systems, because no such path was ever built.

That is the case for registering us at a lower tier than a vendor with production access.

Where your data is processed, and who that rules out

This is near the front because for some buyers it decides the question, and everyone's time is better spent knowing now.

Noctovisor runs on a virtual private server from OVH, contracted through OVH's Polish entity. The server is physically in Canada. The database and the monitoring pipeline both run on it. There is no European copy of the live system. Backups sit in Canada plus a second copy in Warsaw. Language models are Anthropic, xAI, OpenAI and Google, in the United States. The mailbox that receives your list is Google Workspace, with its data region set to Europe, so your list is held in the EU before anything reaches Canada. Nothing else in this chain sits inside the EEA except the Warsaw backup copy.

What that means for a European buyer:

  • Canada holds a European Commission adequacy decision, confirmed in force on 15 January 2024. We rely on it supplemented by standard contractual clauses with the hosting provider, so the transfer stands on either basis. The clauses are there for a reason worth naming: 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.
  • Every transfer to a US provider, including the language model providers, is treated as needing standard contractual clauses. We do not rely on a provider's Data Privacy Framework certification on its own.
  • If you are a financial entity under DORA, non-EU hosting is a disclosure obligation rather than a prohibition. Your register of information records the country of processing, and for Noctovisor that is Canada, with the US providers named above.
  • If your own policy requires that data stay in the EU or EEA, Noctovisor does not meet that requirement today. Not partially, and not with a configuration change. Better said now.

There is no choice of processing region.

Providers

  • OVH: the server that runs the database and monitoring. Canada, contracted through its Polish entity.
  • Cloudflare: nameservers, reverse proxy, website hosting, and the tunnel carrying the comment page. Your answer to an alert passes through its network in transit and is not stored there; no customer list, finding or alert passes through it.
  • Anthropic, xAI, OpenAI and Google: language models for drafting and translating alert text, and for the automated check of each alert against its source. US.
  • Google (Workspace): receives the lists and instructions customers send to contact@noctovisor.com, and holds them. The data region is set to Europe, so your list is held in the EU rather than crossing to the US before it reaches Canada. Some service metadata sits outside that setting's scope and may be processed in the US.
  • Resend: outbound alert delivery, sending from the subdomain alerts.noctovisor.com. US.

The database is self-hosted on the OVH server, so no third-party database provider ever holds your data. Card payment runs through Stripe, on a page Stripe hosts, so no card data exists in any system we run and the website loads no code from it. There is no analytics on the website; the page carries no third-party scripts, which you can confirm by viewing source. There is no error monitoring service and no log management service.

The sub-processor list is a separate document, kept current, and available before you send us anything. You get at least 30 days' notice by email before a new sub-processor is added, and a right to object on reasonable data protection grounds in that window. An urgent replacement made to protect security or continuity is notified within 5 business days, and the same right to object runs from then.

Controls, briefly

Access. There are no customer accounts, so your own access controls are the ones that apply to our output. Alerts land in mailboxes you nominate, inside your tenant, under your MFA and your leaver process. Administrative access to Noctovisor's systems is restricted, with no shared accounts, unique credentials per service, and multi-factor authentication where the provider supports it.

Encryption. Public endpoints are HTTPS only, verifiable from outside. Traffic to third-party APIs is TLS. Email is encrypted in transit between well-configured providers but is not end-to-end encrypted, and we cannot secure a mailbox we do not run. Alerts carry company names and facts already published publicly. If your policy requires encrypted delivery, say so before you start, because email is the whole product.

Encryption at rest. The server volume holding the database is encrypted, and so is the hardware holding the Warsaw backup. The database is self-hosted rather than a managed service, so encryption at rest is ours to switch on rather than a platform default someone might reasonably assume.

Secrets. Service credentials live in encrypted credential stores and a password manager for administrative logins. Nothing in the code repository.

Backups and recovery. Backups are held in Canada with a second, independent copy on our own encrypted hardware in Warsaw. They run daily and are kept for 30 days. Everything runs on one server, so there is no failover and no second region: losing it stops monitoring until it is rebuilt. We do not publish an RTO or RPO without operating history to support one. What the product's shape gives you regardless: alerts already delivered are in your mailbox, not on our server, so if you export your record quarterly the evidence survives the total loss of Noctovisor.

Logging. Every alert is recorded with what was sent, when, to whom, and its source. Weekly summaries too, which is the dated proof the watch ran in quiet weeks. That log is what an evidence export is built from.

Change management. Private git repository, changes on a branch, scripted and reversible deployment with rollback to a known-good version.

Patching. The network layer and the mailbox are patched by their providers. The self-hosted stack (operating system, database, pipeline software) is our responsibility: critical and high-severity updates promptly, everything else reviewed and applied at least monthly. No software versions are published here, deliberately.

Language models

Anthropic (Claude), xAI (Grok), OpenAI and Google (Gemini). All US.

  • None trains on the data we send. That is the commercial API position for all four, not a setting that could be forgotten.
  • All four delete API inputs and outputs within thirty days: three by default, and Google because we set its log-retention window below its default. Content flagged under a provider's usage policy may be retained longer under that provider's terms, which applies to flagged material rather than ordinary traffic and is stated here rather than left to be discovered.
  • Each provider has some form of zero-retention arrangement, and none is in place today. Three of the four grant it only on application and approval, so it is not simply a switch we have left off. That is an unfavourable fact you would otherwise have to ask for, so it is here. If that changes, this line changes.
  • Inference is not pinned to a region. Prompts are processed in the United States.

The models see company names, domains and public source material. They do not see contracts, spend, or anything you never sent.

One exposure specific to this product: the pipeline reads untrusted content from public websites and passes it to a language model, so a page crafted to carry instructions could try to change what an alert says. Retrieved content is handled as data rather than instruction, and the verification step reads the source itself.

Alert integrity

Accuracy is a security property here, because your team may act on an alert.

Every name on your list is resolved to a registered legal entity before monitoring starts, and every alert names the identifier it matched. Most false alarms in this category of product are true facts about the wrong company, and that line is what lets you catch it in seconds.

Every alert links to its primary source, and a second model-based check reads the claim against that source before delivery. Its job is to disagree. It is a machine checking a machine, so treat it as a strong filter rather than a guarantee. That is also why the source link is on every alert.

Which findings reach your weekly log is decided automatically against the criteria you gave us, and a person reads every alert and every weekly log before it is sent.

If an alert is wrong, forward it. It gets corrected and the correction is logged.

Incidents

If there is a personal data breach affecting your data, you are notified without undue delay and within 24 hours of our becoming aware, with what is known at the time rather than waiting for a complete picture. Your own Article 33 clock is 72 hours and it starts from the same event, so taking all 72 ourselves would hand you a deadline instead of a warning. The same clause is in the data processing agreement.

  • "Becoming aware" is not detection: something starting overnight is likely noticed the next morning, and the clock runs from then.
  • If your own notification clock is shorter (Reg S-P puts 72 hours on your notification about a service-provider incident), tell us before you sign.
  • You are told when monitoring stops, not only when it resumes.
  • You get a written follow-up once the cause is understood, for your own incident file.

If OVH or Cloudflare has an outage, we are a customer like anyone else. You will be told what is affected, and not told we are fixing something we have no access to.

Continuity and exit

If the service is interrupted for an extended period, monitoring stops, and you are told. What genuinely limits the consequence, all of it checkable:

  • Monthly billing, no annual commitment, no notice period. Maximum exposure is one month.
  • Nothing to unwind. No integration, no installed software, no credential to revoke. Stopping Noctovisor is stopping an email.
  • The evidence is already yours. Every alert and weekly summary is in your mailbox, in your tenant, under your retention policy. If Noctovisor vanished overnight, the history of what you were told and when survives, because it was never only on our server.
  • Exports on demand, in a non-proprietary format, including on the way out.
  • Replacing us is not a programme. Another service, or a person with a checklist, can pick up a list already cleaned and matched to legal identifiers. You keep the expensive part.

Exit and termination assistance, committed in the same words as the data processing agreement: transition support for up to three further monthly terms at the same monthly fee, with no uplift; a full export of your record on request in a non-proprietary format; written confirmation of deletion once handover is complete.

Certifications

No ISO 27001 and no SOC 2. Nothing here should be read as implying otherwise. We are working toward ISO 27001, with SOC 2 to follow, and will communicate a target date once one is confirmed.

The certifications in this supply chain belong to the providers underneath, and the sub-processor list points to their attestations so you can check rather than take our word. Be exact about what that covers: those reports cover the platforms. The self-hosted database and pipeline on top of the server are not yet covered by an independent audit, and closing that gap is what ISO 27001 is for.

What exists today instead, all of it before you send us anything: this summary, a data processing agreement, the sub-processor list, a privacy policy, a redacted sample export so your audit function can read the real output rather than a description of it, and a written answer to any specific question.

Reporting a vulnerability

Email contact@noctovisor.com with "security" in the subject line and it gets read first. You will get an acknowledgement and a straight answer about whether it is being fixed and roughly when. There is no bug bounty. If you want credit, you get credit.

Good-faith research is welcome within limits: do not test the live alert pipeline, do not run denial-of-service tests, do not submit another company's list, and do not access or alter data that is not yours. Noctovisor has never taken and does not intend to take legal action against anyone who finds a problem, stays within those limits, and reports it privately before publishing.

Version 1.11, 26 August 2026. Contact: contact@noctovisor.com