Access & Data Handling

Last updated: September 2026

We ask security teams to point Nowisor at their ServiceNow estate, so we owe you a precise account of what touches your data and what does not. This page is that account. Where it matters, we lead with the option that keeps your data in your hands. Every statement here describes something in the code rather than something in a policy, and where the two would differ we say what the code does.

Who we are, and where your data is processed

Nowisor SASU, Nice, France. The application and its database run in an EU region in the Netherlands (Railway europe-west4), with the database on a persistent volume in the same region.

Customer instance data — your scan findings and the configuration values behind them — is routed to our EU inference path by default, on every plan including the free one: an EU-hosted gateway in Frankfurt with the model pinned to an EU cloud region, under a signed GDPR Article 28 DPA. Internal work that touches no customer instance data, such as knowledge-base drafting, uses a US-hosted provider instead. Connected accounts and above can make a different, explicit choice — Enhanced data protection sends inference to a separate, dedicated Anthropic workspace key rather than the shared one, processed in the US — and an explicit choice is never silently upgraded to something else.

On that EU option we have switched prompt and output logging off at the gateway, so under that DPA it keeps no copy of the request or the response. The model behind it is served by AWS Bedrock in Frankfurt under its own terms, which makes this EU-resident processing with no gateway-side logging rather than end-to-end zero retention. Retention and model-training terms for both are set by our agreements with those providers, not by a setting in this product. What the product itself guarantees is narrower and testable: a request the selected option cannot serve is refused and the credit refunded — it is never re-routed to the standard endpoint.

If your organisation has a specific data-residency requirement (for example, EU-only processing for NIS2 or DORA), contact us before connecting an instance so we can confirm the right option for your case.

Who else is involved

The list below is not a policy statement — it is the outbound allow-list the application enforces at runtime. A destination that is not on it is refused before a network connection is opened, so a vendor cannot quietly join this list without appearing here.

Involved in handling your data

Security intelligence sources, which receive nothing of yours

These are read, never written to: api.github.com, api.vulncheck.com, api.greynoise.io, api.first.org, www.cisa.gov and services.nvd.nist.gov. They supply advisory and exploitation intelligence. No customer identifier, instance name or finding is ever sent to any of them.

The list is what this deployment is configured to allow, and an operator can add a host to it — doing so is announced in the application log when the guard starts, so it is never a silent change. We would rather describe a list that can change than imply one that cannot.

There are no analytics, tag managers or third-party scripts on this site. The only scripts the pages load are our own, and typefaces are served from our own domain.

The outbound boundary

Every outbound call the application makes is checked against that allow-list on protocol and hostname before a socket is opened, and a refused destination raises an error and records a security event rather than failing quietly. The guard is installed during boot and a failed install stops the process, so there is no window in which it is not running. Any destination that is not loopback must be HTTPS, and redirects are followed by the guard itself rather than delegated, with the authorization header dropped whenever a redirect changes host.

What we cannot offer is a fixed set of source IP addresses. Our platform provides no network-level egress control, so if your instance requires inbound IP allow-listing, the upload path below is the route that works today. We would rather say so than publish a range we cannot hold to.

The paste-driven option: your logs never leave your tenant

Our forensic checks — such as the CVE exposure check — run from a read-only Background Script you run yourself on your instance. You paste its output into the page. For our free checks the verdict is computed in your browser: the pasted log text is never transmitted to us. The detection scripts only read log tables and print a result — they cannot write to, change, or call out from your instance. If you need to generate a dated PDF, only the computed verdict (the conclusion) is sent to render it — never the underlying log lines — and the anonymous path stores nothing.

What runs inside your instance, if you choose the upload route

Nothing reaches inward on this route and no credential leaves your side, but something does go in, and it goes in the normal way: a scoped application you install through your own change process, or our five standalone Background Scripts for a reduced review. Both are open source under Apache-2.0, so your reviewer reads the same code we do.

The mechanism, precisely, because it decides who has to be in the room: the application is built and installed with the ServiceNow Fluent SDK, which needs Node and the SDK on the machine doing the install. It is not a plain update-set XML import, and there is no SDK-free install path today. The five Background Scripts need none of that — they are pasted and run — which is why they exist as the lighter option.

What a connected scan reads

A connected scan reads 25 tables over your instance's own REST Table API, and every call carries an explicit field list — we ask for the columns a check needs and no others. It does not modify your instance as part of scanning.

Platform configuration. sys_properties, sys_rate_limit_rules, sn_vsc_instance_hardening_settings — configuration property values (password-type and secret-shaped values are replaced by a marker at the read), rate-limit rules, and your Security Center hardening settings.

Access control. sys_security_acl, sys_security_acl_role, sys_user, sys_user_has_role — ACL rules with their conditions, the roles gating them, and which account holds which role.

Data model. sys_db_object, sys_dictionary — which tables and fields exist, so a check never runs against something your instance does not have.

Server-side code. sys_script, sys_script_include, sysauto_script — business rules by count, Script Includes by name and access level, and scheduled jobs.

Web services. sys_ws_definition, sys_ws_operation — Scripted REST definitions and their operations, for authentication and ACL posture.

Non-human identities and integrations. oauth_entity, oauth_credential, discovery_credentials, ecc_agent — OAuth clients and when each last issued a token, credential records by name and type, and MID Servers.

Applications and plugins. sys_plugins, v_plugin, sys_store_app, sys_scope — which plugins, Store applications and application scopes are installed and active, so a finding can say whether a feature is even present.

AI agents. sn_aia_agent — whether the agentic surface exists on your instance, and what it is permitted to reach.

Knowledge bases. kb_knowledge_base, kb_uc_can_read_mtom — knowledge base read criteria, for public-exposure checks. Article bodies are never fetched.

Three details matter more than the list, because they are the ones a reviewer should challenge. ACL condition scripts are read in full — that is how an over-permissive rule is proven rather than guessed at. Script Include bodies are not: they are matched by a query your instance evaluates, and only the names of matching records come back. And credential records are read by name, type and target only — never a secret value, which is not a column we ask for.

No role is required, verified or enforced by the product at connect time, so we do not publish a role name and call it a requirement. What the integration account needs is read access to the tables above; how your platform team grants that is their call, and the narrower the better.

Writing to your instance

The one write path is explicit and opt-in. Remediation ticketing is the only thing that writes to your instance: it creates a change request or incident when you click to confirm a server-built request you can see first, or when a scan schedule you set opted into automatic tickets, and it adds a work note to, or closes, a ticket it created when a later scan no longer detects the finding, if that schedule opted into it. Nothing is written silently, and no other record is ever modified or deleted.

We do not write to your instance except the remediation-ticket path above.

Credentials, retention and deletion

Trust artifacts

We are a small, focused vendor and we hold no third-party security attestation today. Rather than name a scheme we have not completed, this page states what the code enforces and points at where each control lives, so your reviewer can test the claims instead of taking them. If your procurement process needs one of these to proceed, tell us — and in the meantime, the paste-driven path above lets you get value without connecting anything at all.

Related

How a finding becomes a verdict, what it is compared against, and when it withdraws itself are a different subject with its own page: how verdicts are computed.

Contact

Questions about data handling, a security questionnaire, or a residency requirement? Reach us via the main site and we will respond directly.