The Vendor Security Questionnaire below answers the standard set of NIS2 Art. 21(2)(d) supply-chain assessment questions, GDPR Art. 32 security-of-processing items, and DORA Art. 28-30 ICT third-party provider questions. Buyers may rely on it for due diligence; the source markdown is canonical.

title: NISMap — Vendor Security Questionnaire (VSQ) version: 1.0 date: 2026-05-22 contact: security@nismap.com audience: prospective and existing customers performing supply-chain risk assessment under NIS2 Art. 21(2)(d) / GDPR Art. 32 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 GDPR Art. 32 (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 security@nismap.com.

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: security@nismap.com. Bug bounty / responsible disclosure intake: same address, covered at https://nismap.com/security.

A5. DPO / privacy contact. Combined privacy@nismap.com mailbox (handled by Inger s.r.o.). Inger has not formally appointed an external DPO — current processing volumes do not trigger the GDPR Art. 37 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: docs/21-architecture-overview.md (provided on DD 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. Reference: docs/15-sub-processor-dpa-status.md.

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

Anthropic (Claude API, United States) — receives anonymized prompts (no IČO, no company name, no email, no phone) for AI report generation. Mechanism: EU Standard Contractual Clauses 2021/914 Module 2 (controller → processor). 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 and Turnstile only) — 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 per docs/14-security-scan-report.md §3) 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: src/lib/crypto/secretbox.ts. 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. Source of record: docs/16-pii-encryption-audit.md.

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. Each rotation logged in docs/15-key-rotation-log.md.

D. Access control

D1. Role-based access control. Three guard layers in code: requireAuth (any signed-in user), requireAuditor (auditor role), requireSuperAdmin (operator staff, gated by SUPER_ADMIN_EMAILS env allowlist). Source: src/lib/rbac/.

D2. Row-level security. RLS enforced on all 40 tenant-facing tables in Postgres. Per docs/14-security-scan-report.md §3: 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 under src/app/api/auth/mfa/{setup,verify,validate,status} 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 (docs/12-security-gdpr-ux-gap-analysis-2026-04.md task S9). 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. Hard-coded to a small whitelist via the SUPER_ADMIN_EMAILS env variable. Currently a single human (the founder). Buyer onboarding extends this to operator staff and is part of the post-close handoff.

E. Vulnerability management

E1. Static dependency scanning. npm audit re-run weekly and before every release. Findings logged in docs/14-security-scan-report.md §5. 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 (.github/workflows/ci.yml). Independent SAST tooling (e.g. CodeQL) is not yet wired into CI — flagged for buyer post-close action.

E3. Dependency auto-update. Not currently automated (no Renovate, no Dependabot). Manual npm audit review is performed weekly by the founder. Automation of this is a buyer post-close item.

E4. Penetration testing. Not yet performed. A Tier 2 external security audit (candidate: SOMI Systems, Slovakia) is planned before the first enterprise buyer LOI per docs/14-security-scan-report.md §9 and docs/21-architecture-overview.md §9.

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 founder's email/phone.

F. Incident response

F1. Documented IR process? Yes. The platform's own production incident playbook is at docs/14-bcp-drp.md. 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 (GDPR Art. 33). 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. Per docs/14-bcp-drp.md §4:

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 documented as a residual risk in docs/14-bcp-drp.md.

H. Sub-processors

H1. Current sub-processor list. Published at https://nismap.com/sub-processors and tracked internally in docs/15-sub-processor-dpa-status.md. As of 2026-09-24 the list is: Hetzner Online (EU, Germany — application hosting), Supabase (EU), Anthropic (US, anonymized only), Stripe (IE/US), Resend (US), PostHog (EU Cloud), Cloudflare (US — DNS and 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 — each row in docs/15-sub-processor-dpa-status.md links to the published DPA URL and records the transfer mechanism. Re-verified quarterly.

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 privacy@nismap.com. 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). 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)) — service delivery, billing.
Legitimate interest (Art. 6(1)(f)) — security logging, abuse detection (balancing test on file).
Consent (Art. 6(1)(a)) — 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 (GDPR Art. 12-22)

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 docs/16-pii-encryption-audit.md and the privacy notice.

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

K1. Mechanism per sub-processor. See docs/15-sub-processor-dpa-status.md. 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 (anonymization for Anthropic).

K2. Transfer Impact Assessment (TIA). Drafted internally for Anthropic (docs/15-sub-processor-dpa-status.md "Anthropic deep dive"). 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. A Tier 2 external security audit is planned before the first enterprise buyer LOI (docs/21-architecture-overview.md §9). Candidate: SOMI Systems (Slovak NIS2 auditor).

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. Headcount with access to customer data. One — the founder (Julius German, Inger s.r.o.), acting in dev, ops, security, and support roles. No subcontractors or freelancers have production access.

M2. Background screening. Not applicable at headcount = 1; the founder is the principal of the contracting entity. Buyer operator will implement standard pre-employment screening as part of the post-close personnel policy (docs/13-operator-runbook.md).

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

M4. Termination of access. Single-person operator today, so this is a theoretical control. The post-close operator runbook (docs/13-operator-runbook.md) prescribes immediate revocation of server (SSH), Supabase, GitHub, Sentry, Stripe access on personnel departure.

N. Code & change management

N1. Source control & review. Git on GitHub. All commits authored by the founder; commit metadata is single-author. There is no separate code-reviewer today. A second-reviewer policy is part of the operator handoff.

N2. CI gates. .github/workflows/ci.yml 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 (image.yml); deploy.yml then deploys that image to the application server and runs a smoke test with automatic rollback. Migrations are applied via .github/workflows/apply-migrations.yml with explicit operator approval and supabase-schema-check.yml drift detection.

N4. Secret management. Environment variables on the application server and GitHub Actions secrets (no secrets in repo). .env.example enumerates required variable names without values. Pre-commit hygiene plus periodic gitleaks sweep across full git history (planned — docs/14-security-scan-report.md §9 item 4).

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 founder'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 src/app/api/cron/retention/route.ts weekly Sunday 04:00 cron.

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 src/app/api/cron/retention/route.ts; documented in the privacy notice and in docs/16-pii-encryption-audit.md.

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, per docs/legal/info-memorandum-v1-en.md). 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	security@nismap.com
Privacy, DSAR, DPA requests	privacy@nismap.com
Commercial / billing	support@nismap.com
Vulnerability disclosure	security@nismap.com (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), DORA Art. 28-30, and GDPR Art. 28 / 32 supplier-assessment requirements.

Trust & Vendor Security