Technical and Organizational Measures

Not applicable. QuoteXelerator, a HubSpot Marketplace application operated by Nomadyr UG (haftungsbeschränkt), does not operate its own physical servers. All infrastructure is provided through cloud services. Physical access control is the responsibility of the sub-processors:

• Supabase: Hosted in Frankfurt, Germany (AWS eu-central-1). SOC 2 Type 2 certified. AWS documents the following physical security controls: multi-factor authentication at access points, CCTV video surveillance, and 24/7 professional security staff (source: aws.amazon.com/compliance/data-center/).
• Vercel: Serverless Functions in Frankfurt, Germany. SOC 2 Type 2 certified. Infrastructure operated in certified data centers.

• Strong passwords and two-factor authentication (2FA) for all administrative accounts
• Individual administrator accounts, no shared credentials
• Supabase dashboard access via 2FA
• Vercel dashboard access via 2FA
• GitHub repository access via 2FA and SSH key authentication
• API keys stored as environment variables, never in source code
• Regular review and rotation of access credentials
• Principle of least privilege applied to all system access
• Automatic session timeouts on inactivity

• Role-based access control (RBAC) in the application
• Per-customer data isolation at the database level through Row-Level Security (RLS) policies
• HubSpot OAuth uses minimal permissions (scopes): only the permissions required for quote transformation are requested
• Sensitive fields (OAuth tokens, recipe configurations, quote snapshots) are encrypted at the application layer with per-portal unique keys. These fields cannot be read in plaintext, even with direct database access
• Customer identifiers use opaque, non-sequential references to prevent enumeration
• Database access permissions are strictly restricted: application roles have only the minimum required permissions (SELECT, INSERT, UPDATE) on their respective tables
• Access logging for all administrative actions
• No direct database access during normal operations; all data manipulation occurs through the application layer

Customer benefit. You can rely on this: before technical logs are used for debugging or service improvement, personal data such as email addresses, access tokens, and known secret formats are automatically removed. We and the supporting AI tooling see only the anonymised technical context of an error, never your customer data. The redaction is pattern-based; a residual risk remains and is limited by short retention periods, contractual safeguards (Standard Contractual Clauses Module 3, explicit training exclusions), and encryption in transit.

The redaction pipeline is structured as seven cooperating layers. Each layer addresses a different failure mode: pattern misses, schema drift, oversize values, missing audit trail, silent leaks, regression, and observability. Together they make a PII leak unlikely and observable to us.

Layer 1: Pattern Redaction (ingestion-time scrub).

• Ingestion-time scrub. All technical logs and incident payloads pass through a deterministic pattern-based redaction layer at ingestion, before storage.
• Patterns covered. The redaction routine replaces the following PII and secret patterns with placeholder tokens before any payload leaves the system:

  Pattern	Replacement
  Email addresses	a***@redacted
  Bearer tokens	Bearer [REDACTED]
  Stripe API keys	sk_[REDACTED], pk_[REDACTED]
  HubSpot Private App Tokens	pat-[REDACTED]
  JSON Web Tokens	[REDACTED_JWT]
  Long hex sequences (HMAC/SHA-256 digests)	[REDACTED_HEX]
  IBAN (EU 27-country)	[REDACTED_IBAN]
  International phone numbers	[REDACTED_PHONE]
  German VAT / EU VAT IDs	[REDACTED_VAT_DE] / [REDACTED_VAT_EU]
  German Steuernummer	[REDACTED_TAX_DE]
  AWS access/session keys	[REDACTED_AWS_KEY]
  Anthropic keys	[REDACTED_ANTHROPIC]
  GitHub PATs	[REDACTED_GITHUB]
  Cookie / Set-Cookie headers	[REDACTED_COOKIE]

• Recursive walk. Applied recursively to nested JSON values; object keys are preserved so the technical structure remains debuggable.
• Request-path redaction. Query strings on incident request paths are passed through the same redaction routine before storage; the path portion is preserved verbatim for triage.
• Logger-level hashing. The internal logger additionally hashes customer email identifiers and never logs plaintext quote payloads or deal/line-item content.
• Posture: preventive, not absolute. Custom or unusual token formats may not be caught by pattern matching alone. This is why content scrubbing is one of seven preventive layers (see below); the combination reduces the likelihood of an unusual-format leak. Residual risk is further limited by short retention at the AI provider and the contractual no-training clause.

Layer 2: Field Allowlist (architectural prevention). An allowlist defines which fields may be sent to the LLM. Unknown fields are rejected at compile time. Variable content (e.g. the details field) is reduced before transmission to a closed set of known-safe keys: endpoint, HTTP status, retry count, duration, module, function. Free-text fields are typed as "redacted", so raw content cannot reach the egress path.

Layer 3: Egress Schema Validation. Before any transmission, a strict schema verifies that only expected fields with valid content and within hard length caps are present. Unknown fields, oversize values, and invalid values block the transmission fail-closed. Violations are logged by field name only, never by content.

Layer 4: Transmission Audit Log. Every LLM transmission is logged in an audit table: incident reference, timestamp, target model, SHA-256 hash of the redacted prompt, size, and validation status. No raw content is stored. Controllers receive their portal's audit trail as a CSV export on written request to legal@quotexelerator.com.

Layer 5: Egress-Block Alert. If the egress check ever blocks a transmission (i.e., a leak slipped past Layers 1-3), the operation is aborted and an immediate email alert is sent to our internal data protection contact. The alert contains the incident id, hash, and matched pattern, never raw values. Investigation and pattern updates begin without undue delay once we become aware (receipt of the alert).

Layer 6: Weekly Canary Regression Tests. A scheduled weekly CI job tests the redaction pipeline with synthetic test payloads of the known PII patterns (see table above). If a single pattern is missed, the system automatically opens a security-incident ticket.

Layer 7: Sampled Prompt Spot-Check. Approximately 5% of redacted prompts are stored in full for periodic spot review. Sampling uses a cryptographically secure random source, so the selection cannot be steered. This complements the hash-only audit trail with content-level verification.

• Effect. We, the AI-assisted incident-investigation tooling, and any external incident-investigation system see redacted technical context only, never raw customer data.
• Layer interaction. The seven layers act in concert: content scrubbing, field allowlist, schema validation, audit trail, proactive alerting, regression canaries, and content sampling. The combination makes a PII leak unlikely and observable to us.
• Residual risk acknowledged. Residual risk remains acknowledged: unknown PII formats, sub-pattern matches, vendor-side compromise, individual layer failure.
• Residual-risk limitation. Short retention at Anthropic (inference logs and Trust-and-Safety logs), contractual no-training warranty under the Anthropic Commercial Terms, encryption in transit (TLS 1.2+), Standard Contractual Clauses Module 3 (2021/914), documented Transfer Impact Assessment on file.

We use AI-assisted code-authoring tools (e.g. Claude Code) during development. These tools transmit code and context to their respective provider (e.g. Anthropic) during use for processing. By internal policy, production customer data is never entered into these tools. Connected Supabase connectors only access already-redacted incident records (see §3a). For these reasons, such tools are not listed as customer-facing sub-processors.

• All data encrypted in transit (TLS 1.2+)
• All data encrypted at rest (AES-256)
• Application-layer encryption ensures sensitive data remains protected even in the event of unauthorized database access. Encryption keys are cryptographically isolated per customer portal
• No plaintext credentials, access tokens, or authentication secrets are stored in the database
• All QuoteXelerator infrastructure (database, compute) is hosted in the EU (Frankfurt, Germany). QuoteXelerator does not replicate CRM master data (contacts, companies, conversations, emails); for audit and idempotency purposes, only encrypted snapshots of processed quotes and references to created deal line items are stored. Reads and writes to the HubSpot portal occur directly via OAuth following a minimal-footprint principle
• Stripe payment data is processed by Stripe Payments Europe, Ltd. (Dublin). No payment instrument data is stored in the QuoteXelerator database
• HTTPS enforced on all endpoints; unencrypted HTTP connections are automatically redirected
• Standard HTTP security headers are set on all responses

• Complete audit logging of all data changes with timestamps and user identifiers
• Application-level logging of every quote transformation
• Immutable snapshots for every processed quote; changes to processed data are traceable and auditable
• Tracking of changes to deal line items after creation
• Audit logs cannot be modified or deleted by application users (append-only principle)
• Logging of all administrative actions, including configuration changes

• Customer data is processed exclusively for the contractually agreed purpose (quote transformation)
• Data processing agreements (DPA) with all sub-processors
• No use of customer data for training, marketing, or secondary purposes
• Processing bound by instructions pursuant to Art. 28(3)(a) GDPR
• Data minimization: only the data required for the processing purpose is collected and processed
• No replication of CRM master data (contacts, companies, conversations, emails); only encrypted quote snapshots and references to created deal line items are stored for audit and compliance purposes. Access to the HubSpot portal occurs directly via OAuth

• Automated daily backups with multi-day retention, managed by the infrastructure provider
• Redundant deployment across the EU region
• Serverless architecture eliminates single points of failure; requests are automatically distributed across available resources
• Monitoring and alerting for outages and performance anomalies
• Automatic scaling under increased load
• Regular verification of recovery capabilities

• Logical separation of customer data through database-level isolation policies (Row-Level Security)
• Each customer has isolated data at the database level; no customer can access another customer's data
• Per-portal unique encryption keys ensure that even if database-level isolation were bypassed, data remains unreadable without the corresponding key
• Tenant isolation is verified through automated tests
• Separate environments for development, staging, and production

• Encryption keys are managed outside the application database and are not accessible from there
• Each customer portal is cryptographically isolated; data of one portal cannot be decrypted in the context of another portal
• Upon account deletion, the customer's encrypted data is irrevocably deleted; without this data, decryption is no longer possible

• End-user authentication is exclusively via HubSpot OAuth 2.0; QuoteXelerator does not store user passwords
• OAuth tokens are stored encrypted and are not readable in plaintext
• Token refresh occurs automatically and securely per the OAuth 2.0 specification
• Users can revoke access at any time through their HubSpot portal
• No session data is stored server-side in persistent storage; the serverless architecture uses stateless authentication

• Serverless architecture: no persistently running servers that could serve as an attack surface
• Each function executes in an isolated environment and terminates after execution
• No open SSH, RDP, or other remote management access
• API endpoints are protected by a Web Application Firewall (WAF)
• DDoS protection provided by the infrastructure provider at the network level
• Standard browser security headers (including Content Security Policy) are configured

• Version control via Git with protected main branch (branch protection rules)
• Code reviews before merging into the production branch
• Automated dependency scanning for known vulnerabilities
• Regular updates of all dependencies and frameworks
• Input validation at the application level for all user-facing data
• Protection against OWASP Top 10 vulnerabilities (SQL injection, XSS, CSRF) through parameterized queries and secure coding standards
• No secrets stored in source code; all configuration values are injected via environment variables
• Automated build and deployment pipelines with integrity checks

• Defined process for detection, classification, and handling of security incidents
• Data breach notification to the Controller without undue delay upon becoming aware, pursuant to Art. 33 GDPR and the DPA
• Documentation of all incidents, including root cause analysis and countermeasures taken
• Monitoring and automated alerting for unusual access patterns or error rates
• Regular review and update of incident response procedures
• Security incident contact: security@quotexelerator.com

• HubSpot OAuth scopes are restricted to the absolute minimum required for quote transformation
• No replication of CRM contacts, conversations, or other CRM master data; QuoteXelerator reads and writes directly to the customer's HubSpot portal
• Processed quote data is stored as encrypted snapshots; raw data is not retained after transformation
• Usage metadata is used exclusively in aggregated, anonymized form for service improvement
• Automatic data deletion after contract termination per the timelines set out in the DPA

The canonical, versioned sub-processor list is maintained in DPA Annex 3 (v1.0, 17 May 2026). The summary below is for orientation only; Annex 3 controls in case of conflict.

• Supabase Inc. / Supabase Pte. Ltd., 970 Toa Payoh North #07-04, Singapore 318992 (exact contracting entity per signed DPA): primary Postgres database, authentication, storage. Processing in AWS eu-central-1, Frankfurt. Transfer: SCCs Module 3 (extra-EU contracting entity); the data flow itself is EU under normal operation. SOC 2 Type II + ISO 27001 (see provider trust portal for current scope IDs).
• Vercel, Inc. (340 S Lemon Ave #4133, Walnut, CA 91789, USA): app hosting and serverless functions. Functions pinned to Frankfurt (fra1), but some edge metadata (IPs, headers) is processed at US edge for DDoS/WAF protection. Transfer: SCCs Module 3 + EU-US Data Privacy Framework (belt-and-suspenders). SOC 2 Type II + ISO 27001 + DPF.
• Resend, Inc. (San Francisco, CA, USA): transactional email delivery (subscription confirmations, payment failures, cancellations, founding-member emails, waitlist confirmations). Account data, logs, and email metadata are stored by Resend in the US, regardless of selected sending region. Outbound SMTP traffic is EU-routable (Ireland); the metadata persistence is not. Transfer: SCCs Module 3 + EU-US DPF (Resend DPF certification Feb/Mar 2025). DPA in place.
• Anthropic, PBC (US): AI inference for the incident investigator (see §3a). Inputs are PII-redacted before transmission and are not used for model training (Anthropic Commercial Terms). Transfer: SCCs Module 3. TIA available on request. Certifications: ISO 27001:2022, ISO 42001:2023, SOC 2 Type I+II, HIPAA-ready.
• GitHub B.V. (Amsterdam, Netherlands; Microsoft regional model): source control and GitHub Actions for the incident-investigator workflow. Sees redacted incident payloads only. Transfer: SCCs Module 3 + EU-US DPF. ISO 27001 + ISO 27018 + SOC 2.
• HubSpot Ireland Limited (Ground Floor, Two Dockland Central, Guild Street, Dublin 1, Ireland): dual role: (a) the reseller-customer's own processor for data that remains in their HubSpot portal (HubSpot is NOT a sub-processor of Nomadyr UG for that data); (b) Nomadyr's sub-processor for portal data cached in Supabase via OAuth (deal IDs, contact email for notifications, line-item snapshots, OAuth/refresh tokens). Transfer: EU adequacy when the customer portal uses HubSpot's EU-residency option; otherwise SCCs Module 3 + EU-US DPF (HubSpot, Inc., USA). SOC 2 Type II + ISO 27001 + ISO 27018 + DPF.

Independent controllers (not sub-processors). Stripe Payments Europe, Limited (1 Grand Canal Street Lower, Dublin, D02 H210, Ireland) processes payment data as an independent controller under Art. 4(7) GDPR for payment processing, fraud prevention, and AML/KYC compliance. Stripe is therefore NOT a sub-processor of Nomadyr UG. Refer to Stripe's own DPA at stripe.com/legal/dpa and DTA at stripe.com/legal/dta. PCI DSS Level 1 certified.

Transfer mechanism. Supabase processes data in Frankfurt (eu-central-1). Vercel functions are pinned to Frankfurt (fra1), but some edge metadata is processed at US edge for DDoS/WAF protection. Stripe acts as an independent controller for payment data; refer to Stripe's own DPA. Each transfer relies on Standard Contractual Clauses Module 3 (Commission Implementing Decision (EU) 2021/914) plus the EU-US Data Privacy Framework where active. Residual third-country risk (FISA 702, EO 12333, Cloud Act) is acknowledged and mitigated by encryption in transit and at rest, data minimisation, pattern-based redaction (§3a), no-training warranties, and short retention.

Notification. The Controller receives at least 30 calendar days advance notice of any new or replacement sub-processor, with a 10-business-day objection window per the DPA notification clause.