---

title: NISMap — Vendor Security Questionnaire (VSQ) version: 1.0 date: 2026-05-22 contact: [email protected] audience: prospective and existing customers performing supply-chain risk assessment under NIS2 Art. 21(2)(d) / Art. 32 GDPR scope: NISMap SaaS platform (nismap.com) operated by Inger s.r.o.

NISMap — Vendor Security Questionnaire (VSQ)

Pre-filled vendor security questionnaire published by NISMap so customers subject to NIS2 Art. 21(2)(d) (supply-chain risk management) or Art. 32 GDPR (security of processing) can incorporate NISMap into their own supplier register without bilateral back-and-forth.

This document is the canonical source. A customer may instead use their internal CAIQ / SIG / VSAQ template — we will copy the answers below into it on request. Send the request to [email protected].

Scope: facts as of 2026-05-22. Re-issued on each material change. Customers are notified by email and via this page when sub-processors, hosting region, or certifications change.

Update 2026-09-24: since 2026-06-29 the application runs as a Docker container on a server operated by Inger s.r.o. at Hetzner Online GmbH (Germany), no longer on Vercel. Sections B, C, G, H, K, M, N and O reflect that; backup statements in G are limited to what is confirmed.

Honesty disclaimer: NISMap is a small operator and this document is honest about that. Where a control is not yet in place, the answer says so. Embellishment would be caught at customer DD and we won't do it.

---

A. About the vendor

A1. Legal entity providing the service. Inger s.r.o., a Slovak limited liability company.

A2. Company ID (IČO) and registration. IČO 50178831, VAT ID SK2120217781, registered office Azalková 6524/10, 974 01 Banská Bystrica, Slovakia. Registered in the Commercial Register of the District Court Banská Bystrica, Section Sro, Entry No. 29266/S (also listed at /imprint).

A3. Headquarters / data-controller jurisdiction. Slovak Republic (European Union).

A4. Website and public security contact. https://nismap.com — security inquiries: [email protected]. Bug bounty / responsible disclosure intake: same address, covered at https://nismap.com/security.

A5. DPO / privacy contact. Combined [email protected] mailbox (handled by Inger s.r.o.). Inger has not formally appointed an external DPO — current processing volumes do not trigger the Art. 37 GDPR mandatory appointment criteria. Customers requiring a named DPO contact for DPA purposes can request a designated point of contact in writing.

---

B. Product, hosting & data residency

B1. What service is provided? A SaaS web application (Next.js) for NIS2, DORA, and GDPR self-assessment, technical security scanning of customer public infrastructure, AI-assisted report and policy generation, an auditor marketplace (in preparation — no auditors listed yet), and incident-management tooling. Detailed architecture is available to customers under NDA on request.

B2. Where is the application hosted? Self-hosted: a Docker container (Next.js standalone) on a server operated by Inger s.r.o. at Hetzner Online GmbH, Germany, behind a Caddy reverse proxy. Images are built in GitHub Actions and pulled from GitHub Container Registry; deploys pin an image tag and roll back automatically if the post-deploy smoke test fails.

B3. Where is customer data stored? Supabase Postgres + Auth + Storage, EU region eu-central-1 (Frankfurt, Germany). No customer business data leaves the EU at rest.

B4. Are there any third-country data transfers? Yes, narrowly scoped:

• Anthropic (Claude API, United States) — receives prompts for AI reports, assessments, document pre-fill and the chat. Every request passes an automatic redaction step that removes IČO, the known company name, emails, phone numbers, IP addresses, birth numbers and heuristically recognised personal names and postal addresses; names or addresses without a recognisable cue (title, label, common given name, postcode) can remain, mainly in uploaded documents and chat text. Mechanism: EU Standard Contractual Clauses 2021/914 Modules 2 and 3 (see the transfer section below). Anthropic does not train on API inputs/outputs by default and we have not opted in.
• Stripe (Ireland / United States), Resend (United States), Cloudflare (United States; DNS, CDN/reverse proxy and Turnstile) — covered by their respective DPAs and SCCs. Data categories listed in /sub-processors.

B5. Multi-tenant or single-tenant? Multi-tenant SaaS. Tenant isolation enforced by Postgres row-level security (RLS) policies on every business table (40 tables with RLS enabled) and tenant_id / org_id foreign keys.

---

C. Encryption

C1. Encryption in transit. HTTPS on all public endpoints (TLS 1.3 negotiated, TLS 1.2 accepted), terminated at the Caddy reverse proxy on the application server and at Supabase. HSTS enabled (max-age=63072000; includeSubDomains; preload). Plain HTTP only answers with a 308 redirect to HTTPS.

C2. Encryption at rest — platform. Supabase storage and Postgres volumes are encrypted at AES-256 disk-level by the underlying cloud provider (AWS, EU region). Supabase manages the keys.

C3. Application-layer encryption of secret tokens. Long-lived secret tokens (e.g. third-party API keys held on behalf of a tenant) are sealed with libsodium secretbox (XSalsa20-Poly1305 AEAD) before insertion. Implementation details are available to customers under NDA on request. Payload format nismap:v2:<key_id>:<nonce>:<ciphertext> so encrypted blobs are key-rotation-aware.

C4. Column-level encryption of PII. feedback.contact_email is sealed with pgcrypto pgp_sym_encrypt; key lives in Supabase Vault; admin reads go through a SECURITY DEFINER view. auth_attempts.email is stored only as a salted SHA-256 HMAC. IP addresses in auth_attempts are stored only as salted hashes. user_sessions.ip_address is truncated to /24 (IPv4) or /48 (IPv6) on insert.

C5. Key management. Encryption keys split across:

• Supabase Vault (feedback_pii_key) for column-level PII;
• Environment variables on the application server (KC_TOKEN_SECRET_KEY, EMAIL_HASH_SALT, IP_HASH_SALT), outside the repository, for application-layer secrets and hash peppers.

C6. Key rotation policy. Annual rotation by default; immediate rotation on any suspected leak or staff departure. Multi-key rotation window supported: KC_TOKEN_SECRET_KEY_PREVIOUS accepts a comma-separated list of retired keys so existing ciphertext stays readable during rollover.

---

D. Access control

D1. Role-based access control. Three guard layers in the application: requireAuth (any signed-in user), requireAuditor (auditor role), requireSuperAdmin (operator staff, gated by SUPER_ADMIN_EMAILS env allow-list).

D2. Row-level security. RLS enforced on all 40 tenant-facing tables in Postgres. 78% of all migrations carry an ALTER TABLE ... ENABLE ROW LEVEL SECURITY statement; the remaining 22% are seed/lookup tables that do not hold user-writable data. Service-role key bypass is used only from backend cron and admin routes that are themselves gated.

D3. Multi-factor authentication. Supabase Auth MFA (TOTP) is wired into the codebase in the application and is available as an opt-in for every signed-in user. It is not yet mandatory for any role; mandatory enforcement for operator staff (super-admin) and auditors is scheduled (planned). Customers with stricter requirements can enforce MFA on their own user accounts today.

D4. Audit logging.

• audit_log table — append-only via RLS + DB trigger, 7-year retention per migration 037 and the weekly retention cron.
• events table — business audit log (logins, scans, incident reports, downloads).
• ai_event_log (migration 074) — every Claude API call (prompt hash, model, route, tenant).
• kc_events (migration 066) — token/key control events.

D5. Operator (super-admin) access. Restricted to a small allow-list of named operator accounts via the SUPER_ADMIN_EMAILS environment variable.

---

E. Vulnerability management

E1. Static dependency scanning. npm audit re-run weekly and before every release. Findings are tracked internally (internal record, available to customers under NDA on request). As of 2026-05-11: 0 critical, 0 high; 5 moderate residual vulnerabilities are all transitive inside Next.js's own toolchain (postcss) and tracked for upstream patch.

E2. Code scanning / SAST. TypeScript strict mode in CI; ESLint; npx tsc --noEmit and npm test block merge in GitHub Actions. Independent SAST tooling (e.g. CodeQL) is not yet wired into CI — planned.

E3. Dependency auto-update. Not currently automated (no Renovate, no Dependabot). Manual npm audit review is performed weekly by the operator. Automation is planned.

E4. Penetration testing. An external security audit is planned; not yet performed.

E5. Error & exception monitoring. Sentry (@sentry/nextjs) on both server and client; EU-hosted Sentry project; PII scrubbed at SDK level; on-call alerting to the operator's email/phone.

---

F. Incident response

F1. Documented IR process? Yes. NIS2 Art. 23 incident-classification wizard (24h / 72h / 30-day reports) is also a product feature available to all customers.

F2. Customer notification SLA. For an incident that affects customer data or service availability:

• Initial customer notification within 24 hours of confirmed impact;
• Root-cause and remediation summary within 7 calendar days;
• Final post-mortem within 30 days when the incident is material. The 24h/7d/30d cadence is honoured on a best-effort basis on the Free tier and as a contractual commitment on Pro and Business tiers (DPA Schedule 2). Free tier is provided "as is" with no SLA per Terms § 5.

F3. Personal-data breach notification (Art. 33 GDPR). NISMap as a processor will notify affected customer-controllers without undue delay and at the latest within 48 hours of confirming a personal-data breach, providing the information required to support the customer's own 72-hour controller-to-supervisory-authority notification.

F4. Has there been a notifiable incident? None to date.

---

G. Business continuity & disaster recovery

G1. RTO / RPO targets. (internal record, available to customers under NDA on request):

• Application tier (stateless Docker container): redeploy of a pinned, previously built image from GitHub Container Registry; no application data is stored on the server.
• Postgres (Supabase): recovery depends on the backup features of the Supabase plan in use; current RTO/RPO figures are provided on DD request.
• Object storage: RTO 8 h, RPO 24 h.

G2. Backups. Database backups are managed by Supabase according to the project's plan. Details on DD request.

G3. Backup restore testing. Restore drill evidence is provided on DD request.

G4. Geographic resilience. Single AWS region (eu-central-1, Frankfurt) via Supabase, with multi-AZ within that region. No cross-region active-active. This is a known residual risk.

---

H. Sub-processors

H1. Current sub-processor list. Published at https://nismap.com/sub-processors As of 2026-10-27 the list is: Hetzner Online (EU, Germany — application hosting), Supabase (EU), Anthropic (US, redacted prompts), Stripe (IE/US), Resend (US), PostHog (EU Cloud), Cloudflare (US — DNS, CDN/reverse proxy, Turnstile), Upstash (EU), Sentry (EU), entyrix.com (EU — public company identifiers only).

H2. Change notification policy. NISMap will publish any new sub-processor to https://nismap.com/sub-processors and notify the customer's billing email at least 30 days before the new sub-processor begins processing customer data, allowing the customer to object per Art. 28(2) GDPR. Emergency sub-processor changes (e.g. security-mandated provider swap) may be made with shorter notice and a written explanation.

H3. DPA in place with each sub-processor. Yes. The transfer mechanism is recorded for each sub-processor and re-verified quarterly (internal record, available to customers under NDA on request).

---

I. Data protection (GDPR)

I1. Controller / processor role.

• For customer tenant data (scans, assessments, incidents, documents, users created within a customer organization) — NISMap (Inger s.r.o.) acts as processor on behalf of the customer.
• For NISMap's own marketing, billing, and direct-customer-account data (the contracting party's identity, billing email, payment record) — NISMap acts as controller.

I2. DPA availability. A signed Data Processing Agreement is available on request from [email protected]. Standard DPA template is published at /dashboard/gdpr/dpa (customer-generatable). Schedule 2 enumerates technical and organizational measures (TOMs) consistent with Art. 32.

I3. Records of Processing (ROPA, Art. 30 GDPR). NISMap maintains a ROPA for its own controller-role processing (Inger's customer database, marketing, support). Internal ROPA module: gdpr_ropa (migration 029); customer-facing ROPA generator at /dashboard/gdpr/ropa.

I4. Privacy notice. Published at https://nismap.com/privacy; covers controller-role processing.

I5. Lawful basis.

• Performance of contract (Art. 6(1)(b) GDPR) — service delivery, billing.
• Legitimate interest (Art. 6(1)(f) GDPR) — security logging, abuse detection (balancing test on file).
• Consent (Art. 6(1)(a) GDPR) — marketing communications only (opt-in; profile flag profiles.marketing_consent, migration 073).

I6. Cookies / tracking. No tracking cookies. PostHog runs in cookieless persistence: 'memory' mode. Supabase Auth and Stripe set strictly-necessary cookies (exempt from consent under the ePrivacy Directive). No cookie banner is shown.

---

J. Data subject rights (Art. 12-22 GDPR)

J1. DSAR handling. A gdpr_dsar_requests table (migration 033) plus operator UI at /dashboard/gdpr/dsar handles intake. Statutory deadline: one month from receipt of the request (Art. 12(3)), extendable by two further months for complex or numerous requests; the data subject is informed of the extension and its reasons within the first month (Art. 12(3)).

J2. Data export (Art. 20). Self-service export at /api/account/export — rate-limited to 1 request per hour, returns the requesting user's profile, scans, assessments, and document references as JSON.

J3. Erasure (Art. 17). Self-service /api/account DELETE removes the user account and cascades the supplemental records subject to legal retention requirements (audit-log entries retained 7 years).

J4. Restriction, objection, rectification. Handled via the same DSAR intake; documented in the privacy notice.

---

K. International transfers (Art. 44-49 GDPR)

K1. Mechanism per sub-processor. Summary:

• Hetzner, Supabase, PostHog, Upstash, Sentry — EU hosting, no transfer occurs.
• Anthropic, Stripe, Resend, Cloudflare — EU SCCs 2021/914 (Module 2 controller-to-processor for Anthropic where NISMap is controller; Module 3 processor-to-processor where NISMap is processor) plus the sub-processor's published DPA and additional safeguards (automatic redaction of identifiers for Anthropic).

K2. Transfer Impact Assessment (TIA). A Transfer Impact Assessment for Anthropic is available to customers under NDA on request.

K3. EU–US Data Privacy Framework. Where a sub-processor self-certifies under the DPF, NISMap will rely on the adequacy decision and update the transfer mechanism column. Anthropic's DPA (effective 24 February 2025, https://www.anthropic.com/legal/data-processing-addendum) incorporates SCC Modules 2 and 3 and does not rely on the DPF; SCCs remain the mechanism.

---

L. Audit, certifications & assurance

L1. NISMap own certifications. None at this time. NISMap is not ISO 27001 certified, not SOC 2 certified, not BSI C5 certified.

L2. Sub-processor certifications.

• Supabase (the database tier — holds all customer business data) — ISO/IEC 27001:2022 certified since May 2026, covering the entire Supabase platform (DB + Auth + Storage). Other sub-processor certifications listed where they exist on their public trust pages; NISMap does not republish them.

L3. Independent security audit. An external security audit is planned; not yet performed.

L4. Customer's right to audit. Customers on the Business tier and above may, with 30 days' written notice and no more than once per 12 months, request reasonable evidence of compliance with the DPA (security questionnaire updates, summary of automated scan results, sub-processor list) at no charge. On-site or live-system audit requires a mutually agreed scope and is chargeable at cost.

---

M. Personnel & operations

M1. Personnel with access to customer data. Only authorized personnel of Inger s.r.o. have access to customer data. Access is assigned individually.

M2. Background screening. Background screening is not described here.

M3. Confidentiality / NDA. Authorized personnel are bound by the customer DPA's confidentiality clauses. Any future personnel will sign confidentiality agreements before access provisioning.

M4. Termination of access. Access is individually assigned and immediately revoked when a person leaves, including SSH, Supabase, GitHub, and Sentry access.

---

N. Code & change management

N1. Source control & review. Git on GitHub. There is no separate code reviewer today. A second-reviewer policy is planned.

N2. CI gates. CI runs ESLint, tsc --noEmit, vitest suite, and next build on every PR and main-branch push. Failed CI blocks merge.

N3. Deployment. A push to main builds an image in GitHub Actions; a deployment workflow then deploys that image to the application server and runs a smoke test with automatic rollback. Migrations are applied via a migration workflow with explicit operator approval and schema drift detection.

N4. Secret management. Environment variables on the application server and GitHub Actions secrets (no secrets in the repository). Required variable names are documented without values. Pre-commit hygiene plus periodic gitleaks sweep across full git history is planned (internal record, available to customers under NDA on request).

N5. Bot protection on public endpoints. Cloudflare Turnstile on every public form; Upstash Redis rate limiting per IP + per identifier; honeypot fields on auth and scan endpoints.

---

O. Logs, monitoring & alerting

O1. Application errors. Sentry (@sentry/nextjs) — EU-hosted project, PII scrubbed, alerts to the operator's pager email.

O2. Product analytics. PostHog EU Cloud, cookieless mode, no cross-site tracking. Used for funnel analysis; never shared with sub-processors.

O3. Audit / business event logs. audit_log, events, ai_event_log, kc_events Postgres tables (described in §D4 above). Retention: 7 years for audit_log, 90 days for auth_attempts, 365 days for b2b_leads. Enforced by a weekly Sunday 04:00 retention task.

O4. Uptime monitoring. Container healthcheck on /api/live plus the internal /api/health endpoint. Status page at /status (currently dev-internal; will be customer-facing pre-launch).

---

P. Customer data deletion & retention

P1. Default retention.

• Anonymous scans (no signed-in user): 90 days.
• Sales lead records (b2b_leads): 365 days.
• Sent drip-campaign records: 90 days.
• Closed/completed DSAR records: 3 years (regulatory evidence).
• audit_log: 7 years (NIS2 evidence floor).
• auth_attempts: 90 days.
• Signed-in customer scans and assessments: retained for the duration of the contract plus contractual run-off period.

P2. Account deletion request. Self-service /api/account DELETE purges the user record and cascades supplemental data within the constraints of legal retention. Operator-assisted deletion via DSAR intake (above). End-to-end SLA: 30 days.

P3. Source for these retention windows. Codified in the retention task and documented in the privacy notice.

---

Q. Liability, insurance & financial assurance

Q1. Cyber liability insurance. In negotiation. Inger s.r.o. is in the process of evaluating cyber-liability and D&O policies (target €5–15k/year coverage). No policy is in force as of 2026-05-22. Customers requiring proof of coverage as a contracting precondition should request status before contract signature.

Q2. Contractual liability cap. As stated in the master Terms of Service / DPA, the standard cap is the greater of (a) twelve (12) months of fees paid by the customer in the twelve months preceding the event and (b) €5,000. Higher caps available on the Business tier by negotiation.

Q3. Excluded perils. Customer-side misuse, force majeure, and acts of third parties outside NISMap's reasonable control. See Terms § 6.

Q4. Financial soundness. Inger s.r.o. is a going concern with audited annual accounts filed with the Slovak Commercial Register. Most recent financial statement available under NDA for enterprise procurement review.

---

R. Contact & escalation

Topic	Channel
Security inquiries, VSQ updates, custom questionnaires	[email protected]
Privacy, DSAR, DPA requests	[email protected]
Commercial / billing	[email protected]
Vulnerability disclosure	[email protected] (response within 5 business days)
Customer incident notification	The contact email on the customer's primary account

---

Change log

Version	Date	Change
1.0	2026-05-22	Initial publication (audit fix N6).

---

This document supersedes any prior ad-hoc VSQ responses. Customers may rely on it for supply-chain due diligence under NIS2 Art. 21(2)(d), Art. 28-30 DORA, and Art. 28 and 32 GDPR supplier-assessment requirements.