Information Security Management System — Scope Statement

Founder attestation

I, Peter Sterkenburg, in my capacity as founder and sole operator of NordScope, attest that the information security management system described in this document is the actual operational state of PortalPilot as of the effective date above. This is a self-attestation. NordScope has not engaged a third-party CPA firm or ISO 27001 certification body; procurement reviewers should treat this document as alignment evidence in the same family as the EU Cloud Code of Conduct Phase 1 self-attestation framework, NordScope's signed copy of which is published at portalpilot.io/compliance/eu-cloud-coc-self-attestation.html. Phase 2 third-party attestations are deferred until enterprise-customer demand justifies the audit cost.

— Peter Sterkenburg, 2026-04-30

§1 Organisation profile

NordScope is a Finnish sole trader (toiminimi) operating PortalPilot under domain portalpilot.io. The sole operator is the founder, Peter Sterkenburg. Under GDPR, NordScope acts as data controller for its own operational records (account profile, billing, audit logs) and as data processor for customer-side HubSpot data accessed under OAuth (the customer is the controller of that data — see the public DPA). NordScope has no employees, no contractors with production access, and no subsidiaries.

• Legal form: Toiminimi (sole trader)
• Y-tunnus: 3148476-5
• Country of establishment: Finland (EU)
• Operating product: PortalPilot — a SaaS HubSpot CRM data-quality and RevOps health analyser

§2 In-scope assets

§2.1 Production application

The PortalPilot SaaS at portalpilot.io and api.portalpilot.io. This includes the customer-facing web application, the backend API and edge-function layer, the relational database that holds account and analysis state, and the authentication service. Public legal artefacts: Privacy, DPA, Security, Terms.

§2.2 Customer data

All HubSpot CRM data accessed under customer authorisation (OAuth 2.0), all account metadata stored by NordScope (account profile, encrypted portal credentials, analysis runs, audit logs), and all derived analytics (health scores, recommendations, exports). The full per-field PII inventory — including source, storage, encryption, retention, lawful basis, sub-processor exposure and GDPR-rights mapping — is published at portalpilot.io/trust/pii-inventory.pdf.

§2.3 Operational infrastructure

A single server in EU (Finland), hosted by Hetzner Online GmbH, running:

• A self-hosted Supabase instance providing authentication, the relational database, edge functions, object storage, and the API gateway
• An orchestration control plane (Coolify) for deployment, environment management, and service lifecycle
• A self-hosted Plausible Community Edition analytics instance at analytics.portalpilot.io
• A reverse-proxy layer (Traefik) terminating TLS for all public HTTPS traffic and routing by host header

§2.4 Sub-processors (third-party processors)

Per the public DPA Annex I (see portalpilot.io/dpa §4.1):

Each sub-processor is bound by a data processing agreement that provides protection at least equivalent to NordScope's customer-facing DPA. HubSpot itself is not a NordScope sub-processor — the customer authorises PortalPilot to access their HubSpot portal under their own subscription.

§2.5 Engineering tooling — coding-agent surface

NordScope uses an LLM-driven coding agent (Anthropic Claude Code) as its primary engineering tool. The agent operates within NordScope's security boundary with file-system access to the source repository, Git access to the GitHub repository, and limited operational access (read-only by default; mutating operations such as production database writes, deploys, or credential reads require explicit per-invocation founder approval). Four defensive layers are applied to bound the agent:

1. Permission tightening — high-risk commands (curl, ssh, rm, shell interpreters, environment dumps) require explicit per-invocation founder approval rather than running silently.
2. Automated pre-execution guards — every command the agent attempts to run is screened before execution; attempts to read credential files, exfiltrate via outbound network calls, or perform destructive operations on the source repository are blocked and logged.
3. Counter-prompt-injection canaries — alphabetically-first marker files in sensitive locations (e.g. ~/.ssh/) are designed to redirect the agent to abort and report if it is tricked into reading those locations.
4. Application security — Row Level Security on every customer table, JWT-authenticated edge functions, CORS allow-listing, and AES-256-GCM application-layer encryption of OAuth tokens protect customer data regardless of any compromise of the development-side agent.

Internal counterpart §2.5-internal carries the full hook list, the threat model, and the audit-log review procedure.

§3 Out-of-scope

• The founder's development laptop. The laptop does not host customer data at rest; production secrets are loaded from the production environment, not from local files. Customer data may transit through the laptop during authorised operational work (debugging, support response) but is not retained in source control, local databases, or other persistent stores.
• HubSpot Inc. as a vendor — the customer authorises PortalPilot to read from their own HubSpot portal under OAuth scope; HubSpot is the customer's platform, not a NordScope sub-processor.
• Customer-side HubSpot portal data at rest in HubSpot — the customer holds their own controller role over data within HubSpot.

§4 Network access

The PortalPilot production server is protected by a layered access-control model. Inbound network traffic must pass two independent firewall layers before reaching any service: a cloud-provider firewall at Hetzner's network edge and a host firewall (UFW) on the server itself. Both operate in default-deny mode. The effective allow-list — the intersection of what both layers permit — is:

Anything else is dropped by at least one layer. The two-layer design is intentional defense-in-depth: if either layer fails open, the other still enforces the policy.

TLS terminates at a reverse-proxy layer (Traefik) that routes inbound HTTPS by host header. This separates customer-facing services and administrative services without exposing the underlying ports — both share :443, but reach different backend services depending on the hostname.

All endpoints require application-layer authentication:

• Customer-facing stack (portalpilot.io, api.portalpilot.io): Supabase Auth + JWT + row-level security on every customer table; OAuth 2.0 for HubSpot integration; per-edge-function ownership verification before any portal data access.
• Administrative orchestration plane: built-in session login (email + password) protected by authenticator-app TOTP. 2FA is enabled on the only operator account; under NordScope's single-founder structure this is equivalent to organisational-policy MFA enforcement. Server-wide compulsory enforcement is tracked as a forthcoming enhancement.

No production endpoint is reachable without traversing all of: cloud-provider firewall → host firewall → TLS-terminating reverse proxy → application-layer authentication.

§5 Information classification

NordScope uses a three-tier classification, consistent with the public Privacy and DPA pages:

The full per-field classification, retention period, lawful basis under GDPR, and sub-processor exposure for every PII field is published at portalpilot.io/trust/pii-inventory.pdf.

§6 Roles & responsibilities

Under NordScope's single-founder structure, all roles below are held by Peter Sterkenburg:

Sub-processors hold their own corresponding roles per their respective DPAs (linked from the public DPA). HubSpot is the customer's platform, not a NordScope sub-processor, and the customer holds their own controller role over data within it.

§7 Review cadence

Internal audits are performed by the founder using systematic adversarial review aided by an LLM-driven static-review tool, then re-framed into ISO clause 9.2 form. Each internal audit report is published as a separate compliance artefact and made available to enterprise procurement reviewers on request.

Document history

This document is the canonical ISMS scope for PortalPilot. All Annex A control rows, all risk-register rows, and all SOC 2 Trust Service Criteria mappings within NordScope's compliance pack cite this document by §-number as their root scope reference. An internal counterpart with administrative paths, server identifiers, exact firewall rule lists, key-rotation procedures, and the full agent-security threat model is available under NDA on request.