TenantAtlas/specs/405-dach-trust-datenschutz-security-website-surface/spec.md

Feature Specification: DACH Trust, Datenschutz & Security Website Surface

Feature Branch: 405-dach-trust-datenschutz-security-website-surface
Created: 2026-05-25
Status: Draft
Input: User description: "Create a dedicated public Trust, Datenschutz & Security website surface for DACH evaluation that explains hosting posture, document readiness, data categories, provider permissions, RBAC, auditability, retention, subprocessors, and security contact without unverifiable claims."

Spec Candidate Check (mandatory — SPEC-GATE-001)

• Problem: DACH MSP, Mittelstand, enterprise IT, security, privacy, and procurement stakeholders do not have a single public place to evaluate Tenantial's trust posture without jumping into sales calls or making unsafe assumptions.
• Today's failure: The public website can leave hosting, privacy, permissions, auditability, retention, document readiness, and support-access questions unanswered, which makes the product look immature or invites overclaiming.
• User-visible improvement: A buyer can reach one calm Trust, Datenschutz & Security surface that explains what is known, what is requestable, what is planned, and what is intentionally not claimed.
• Smallest enterprise-capable version: One dedicated public trust page plus homepage/footer/navigation discoverability, a bounded claim-status vocabulary, and explicit claim guardrails for website-only implementation.
• Explicit non-goals: No apps/platform changes, no legal document generation, no DPA workflow, no runtime RBAC or audit implementation, no provider permission runtime logic, no hosting or certification changes, and no fake trust artifacts.
• Permanent complexity imported: One public trust surface, one small public claim-status vocabulary, a few public navigation entry points, and browser/static verification expectations for later website implementation.
• Why now: Spec 404 clarifies positioning; the next blocker in DACH evaluation is trust and legal-readiness clarity before demo, pilot, or procurement review.
• Why not local: A buried paragraph or ad hoc footer copy cannot safely separate verified facts, requestable documents, and future items across the homepage, trust page, and contact handoff.
• Approval class: Core Enterprise.
• Red flags triggered: Trust/compliance claim risk, provider overclaim risk, legal-readiness ambiguity, and public wording that could accidentally turn Microsoft-specific details into generic platform truth.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve

Red Flag Defense

This spec intentionally proceeds despite multiple red flags because the risk is public false assurance, not internal architecture ambition. The narrow solution is a website-only trust surface with cautious wording and explicit status language. No platform abstraction, persistence, provider runtime, legal workflow, or certification framework is introduced.

Scope

This spec defines the public Trust, Datenschutz & Security surface for the Tenantial website.

• Relevant application for later implementation: apps/website
• Depends on: Spec 404 - Public Website Positioning & Content Architecture
• Must not depend on: apps/platform runtime changes
• Primary audience: DACH MSPs, German Mittelstand, enterprise IT, security, privacy, and procurement stakeholders
• Allowed implementation area: public website pages, layout/content/navigation/footer/metadata updates, and website-only validation
• Out of scope: legal operations, contract workflow, AVV/DPA generation, TOM generation, platform RBAC, audit logging runtime, provider permission runtime, hosting changes, certification claims, and support-access governance implementation

Spec Scope Fields (mandatory)

• Scope: N/A - public website surface outside authenticated workspace, tenant, or canonical-view product flows
• Primary Routes: one dedicated public trust route using current website language conventions, plus homepage teaser entry, footer exposure, and any existing public contact handoff used for trust or document requests
• Data Ownership: no workspace-owned or tenant-owned runtime records are created or changed; only public website content, metadata, and navigation exposure are in scope
• RBAC: public read-only content only; no membership, role, capability, or authorization behavior changes

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: N/A - no tenant-context or canonical product view is introduced
• Explicit entitlement checks preventing cross-tenant leakage: N/A - no authenticated product data is involved

Cross-Cutting / Shared Pattern Reuse (mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write N/A - no shared interaction family touched)

• Cross-cutting feature?: yes
• Interaction class(es): navigation, footer links, homepage teaser/CTA, public metadata, contact handoff
• Systems touched: public website shell, primary navigation, footer, homepage trust teaser, public trust route, and public trust/contact handoff
• Existing pattern(s) to extend: existing public website shell and the public content/navigation conventions established by Specs 400-404
• Shared contract / presenter / builder / renderer to reuse: current public website layout, navigation, footer, metadata, and CTA conventions in apps/website
• Why the existing shared path is sufficient or insufficient: the website already has a public shell; this feature should extend that shell instead of creating a parallel trust microsite or one-off legal landing pattern
• Allowed deviation and why: a dedicated trust page and bounded claim-status presentation are allowed because trust review needs one focused destination and explicit current-vs-planned wording
• Consistency impact: tone, CTA behavior, trust-status wording, legal handoff wording, and live-link behavior must stay aligned across homepage, trust page, and footer
• Review focus: verify that trust content uses existing public navigation/footer patterns, exposes only real destinations, and does not create a second public IA language for trust topics

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

• Touches OperationRun start/completion/link UX?: no
• Shared OperationRun UX contract/layer reused: N/A
• Delegated start/completion UX behaviors: N/A
• Local surface-owned behavior that remains: none
• Queued DB-notification policy: N/A
• Terminal notification path: N/A
• Exception required?: none

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

• Shared provider/platform boundary touched?: yes
• Boundary classification: mixed
• Seams affected: public vocabulary for provider permissions, provider-specific versus platform-neutral trust language, data-category descriptions, and current-versus-planned capability wording
• Neutral platform terms preserved or introduced: provider, capability, permission posture, connection metadata, governance evidence, audit context, recovery context
• Provider-specific semantics retained and why: Microsoft Graph permissions remain the concrete first-provider example because Microsoft 365 and Intune are the current public market focus
• Why this does not deepen provider coupling accidentally: the page treats Graph permission names as provider-specific documentation details, keeps the main posture language platform-neutral, and avoids implying broader provider support or platform-wide permission parity
• Follow-up path: follow-up-spec for detailed provider taxonomy, public docs, and automated claim guardrails

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

N/A - public website trust surface only; no authenticated operator-facing product surface is changed.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing surface change.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

N/A - public buyer-facing website copy only; no operator diagnostic or support/raw evidence surface is added here.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing surface change.

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing surface change.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: no
• New enum/state/reason family?: yes - a bounded public claim-status vocabulary for trust statements
• New cross-domain UI framework/taxonomy?: no - page-local trust status language only
• Current operator problem: public evaluators cannot tell which trust statements are verified current facts, requestable documents, planned materials, or intentionally unclaimed areas
• Existing structure is insufficient because: free-form marketing copy does not reliably separate facts, readiness, and non-claims for DACH security, privacy, and procurement review
• Narrowest correct implementation: one focused trust page plus a small website-only claim-status vocabulary applied only where trust topics need explicit current-vs-planned clarity
• Ownership cost: future content upkeep for trust-status wording, live contact destinations, and consistency across homepage, trust page, and later public docs
• Alternative intentionally rejected: unstructured prose with no explicit status model, because it makes false assurance and inconsistent wording too likely
• Release truth: current-release public website truth with bounded preparation for later trust, procurement, and provider-documentation follow-ups

Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser
• Validation lane(s): browser, confidence
• Why this classification and these lanes are sufficient: public trust quality is proven by reachable routes, public content scans, website checks/builds that already exist, and desktop/mobile browser smoke; no platform, database, or provider-runtime lane is needed
• New or expanded test families: none beyond website-only static checks and any existing website smoke coverage
• Fixture / helper cost impact: none or minimal public-site smoke expectations only
• Heavy-family visibility / justification: none
• Special surface test profile: N/A - public website surface
• Standard-native relief or required special coverage: ordinary website coverage only; verify trust readability, live links, no placeholders, and no false trust claims
• Reviewer handoff: confirm only website-facing files change, the trust route is reachable from homepage/footer/navigation, no forbidden claims or fake assets remain, and any hard trust claim is backed by documented verification
• Budget / baseline / trend impact: none expected
• Escalation needed: follow-up-spec if implementation needs legal workflow, platform runtime truth, or non-website contract changes
• Active feature PR close-out entry: Smoke Coverage
• Planned validation commands:
  • inspect package.json and apps/website/package.json
  • run pnpm --filter @tenantatlas/website check if the script exists
  • run pnpm --filter @tenantatlas/website build if the script exists
  • run pnpm --filter @tenantatlas/website test if the script exists
  • run the forbidden-claim and placeholder scan across website source, public assets, and committed generated output when applicable
  • run desktop/mobile browser smoke for the trust route, homepage trust teaser, and footer/navigation links if local preview is available

User Scenarios & Testing (mandatory)

User Story 1 - DACH Evaluator Reviews Trust Posture (Priority: P1)

A DACH MSP or enterprise buyer opens the public trust surface and can quickly understand Tenantial's hosting posture, privacy posture, data categories, permission posture, auditability posture, and document readiness without seeing unsupported legal or certification claims.

Why this priority: This is the core buyer trust gap blocking evaluation after the positioning work in Spec 404.

Independent Test: Can be fully tested by opening the trust page from the homepage or footer and checking whether the required trust topics and status wording are present without false assurance.

Acceptance Scenarios:

1. Given a public visitor on the homepage, When they open the trust surface, Then they can find hosting, privacy, document-readiness, data-category, provider-permission, RBAC, auditability, retention, subprocessor, support-access, and security-contact content in one place.
2. Given a trust topic that is not currently verified as a hard claim, When the visitor reads that section, Then the page uses cautious wording or an explicit non-claim status instead of implying verified compliance or certification.

---

User Story 2 - Procurement Or Privacy Reviewer Requests Documents Safely (Priority: P1)

A procurement, legal, or privacy reviewer needs to see which trust documents are available now, which are request-based, and which are still in preparation so they can decide whether evaluation can proceed.

Why this priority: DACH evaluations often stall on AVV/DPA, TOM, hosting, or subprocessor questions before any pilot begins.

Independent Test: Can be fully tested by reviewing the trust page's document-readiness sections and confirming that only real request paths or real documents are exposed.

Acceptance Scenarios:

1. Given a reviewer reading the AVV/DPA, TOM, or subprocessor sections, When they inspect document availability, Then each topic is clearly marked as documented, on request, in preparation, planned, not claimed, or not applicable.
2. Given a document or request action that is not yet real, When the reviewer reaches that CTA area, Then the page omits the action or routes to a real contact destination instead of using a fake download or placeholder link.

---

User Story 3 - Technical Reviewer Understands Data And Permission Boundaries (Priority: P2)

A technical evaluator needs to understand what categories of data Tenantial handles, what it does not aim to store unnecessarily, and why provider permissions are needed without reading stale or over-detailed permission matrices.

Why this priority: Security and IT reviewers need enough technical clarity to trust the evaluation path without forcing platform-implementation claims onto the public site.

Independent Test: Can be fully tested by reading the data-category and provider-permission sections alone and verifying that the read-versus-write distinction, least-privilege intent, and governance-evidence focus are clear.

Acceptance Scenarios:

1. Given a technical evaluator reading the data-category section, When they compare stored categories, Then governance metadata, provider metadata, policy/configuration evidence, review artifacts, audit metadata, and support/diagnostic context are clearly distinguished.
2. Given a technical evaluator reading the provider-permission section, When they review access posture, Then read-oriented and write-oriented access are distinguished and Microsoft-specific permission details are described as provider-specific documentation rather than generic platform truth.

---

User Story 4 - Public Visitor Can Reach The Trust Surface Easily (Priority: P3)

A public visitor should be able to discover the trust surface from the homepage and footer without hunting through hidden pages or dead links.

Why this priority: Discoverability is necessary for trust content to reduce sales friction instead of becoming an obscure supporting page.

Independent Test: Can be fully tested by navigating through the homepage teaser, footer, and any exposed main navigation links.

Acceptance Scenarios:

1. Given a public visitor on the homepage, When they scan the page or footer, Then a real link to the trust surface is visible.
2. Given a visitor on mobile or desktop, When they use the exposed trust links, Then the trust route opens correctly and no placeholder links appear.

Edge Cases

• What happens when hosting region or operating region is not yet verified? The trust surface must use readiness wording and must not claim Germany or EU hosting as a documented fact.
• What happens when AVV/DPA, TOM, subprocessor details, or a dedicated security mailbox are not yet ready? The page must mark the topic as on request, in preparation, planned, not claimed, or route to an existing general contact path instead of inventing assets.
• How does the system handle an unreviewed exact Microsoft Graph permission list? The page must explain read/write posture and least-privilege intent at a high level without publishing stale permission names.
• How does the system handle website language differences? The trust route and labels must follow the current public website language and routing conventions without introducing a full i18n program in this spec.

Assumptions

• The public website can add one dedicated trust page and a lightweight homepage trust teaser without changing platform runtime or workspace contracts.
• A real public contact path or mailbox either already exists or can be reused for trust/document requests; if not, request CTAs are omitted instead of faked.
• No hard compliance, certification, hosting, or data-minimization claim is treated as verified unless later implementation can tie it to current repo, product, legal, or deployment truth.
• Detailed provider-permission matrices, procurement workflows, and downloadable trust artifacts may follow in Specs 406, 409, 410, or 411 rather than shipping here.

Requirements (mandatory)

This feature introduces no Microsoft Graph calls, no write/change product behavior, no persistence, no OperationRun flow, and no RBAC mutation. Its only structural addition is a bounded public claim-status vocabulary used to prevent false assurance on the public website.

Functional Requirements

Scope And Routing

• FR-001: The implementation MUST remain website-only and MUST NOT require apps/platform runtime changes.
• FR-002: The public website MUST provide one dedicated Trust, Datenschutz & Security page using the current website's routing and language conventions.
• FR-003: The trust page MUST be reachable from the homepage through a visible trust teaser, CTA, or equivalent entry point.
• FR-004: The trust page MUST be reachable from the footer and SHOULD be exposed in main navigation when that fits the current public navigation structure.
• FR-005: Every trust-related link or CTA MUST resolve to a real page, real section, or real contact destination; placeholder links and fake downloads are forbidden.

Trust Surface Content

• FR-006: The trust page MUST open with a calm hero that frames trust, privacy, security, and evaluation readiness without claiming unverified compliance, certification, or hosting facts.
• FR-007: The trust page MUST explain trust principles covering data minimization intent, least privilege, auditability, human approval over blind automation, customer-safe evidence, clear provider boundaries, and DACH evaluation readiness.
• FR-008: The trust page MUST address hosting and operating-region posture using wording that distinguishes documented facts from request-based, in-preparation, planned, or unclaimed items.
• FR-009: The trust page MUST address privacy and DSGVO posture using transparent wording that explains operating intent and data-processing transparency without guaranteeing compliance unless separately verified.
• FR-010: The trust page MUST address AVV/DPA and TOM readiness and MUST distinguish between currently available, request-based, in-preparation, planned, not-claimed, and not-applicable states.
• FR-011: The trust page MUST describe the main public data categories relevant to Tenantial evaluation, including account/workspace metadata, managed environment metadata, provider connection metadata, policy/configuration evidence, findings/exceptions/accepted risks, review/report artifacts, operation/audit metadata, and support/diagnostic context where applicable.
• FR-012: The trust page MUST describe what Tenantial does not aim to store unnecessarily by focusing on productive-content avoidance and governance/evidence focus without claiming that no personal or customer data can ever be stored unless that is verified.
• FR-013: The trust page MUST explain provider permissions at a high level, including why access is needed, how read-oriented and write-oriented permissions differ, and how least-privilege intent and auditability apply.
• FR-014: The trust page MUST treat Microsoft Graph permission names as provider-specific detail and MUST NOT present them as universal platform truth.
• FR-015: The trust page MUST address RBAC/least-privilege posture, auditability, encryption/secrets posture, retention/export/deletion posture, subprocessors, support-access posture, and security contact or security-question handoff.

Claim Status And Guardrails

• FR-016: The trust page MUST expose a small claim-status model wherever trust topics need explicit distinction between current fact, requestable material, planned readiness, or intentional non-claim.
• FR-017: The allowed trust-status vocabulary MUST be limited to documented, on request, in preparation, planned, not claimed, and not applicable, or clearly equivalent wording in the site's active language.
• FR-018: Public trust copy MUST NOT claim DSGVO/GDPR compliance, ISO/BSI/NIS2 certification, German hosting, absence of all customer or personal data, Google/AWS support, automatic restore, autonomous remediation, or equivalent hard assurance unless implementation can document current verification.
• FR-019: If a hard trust claim is published, the implementation MUST record the exact claim, its verification source, and why the claim is safe to publish.
• FR-020: The implementation MUST NOT invent documents, subprocessors, security contacts, certifications, logos, badges, or downloadable legal files.
• FR-021: The implementation MUST NOT use href="#", lorem ipsum, or placeholder legal/trust copy.

Homepage, Footer, And Metadata

• FR-022: The homepage MUST include a lightweight trust teaser or equivalent summary that points to the trust page without duplicating the full trust content.
• FR-023: Footer trust links MUST expose the trust surface and MAY expose privacy/security request actions only when those destinations are real.
• FR-024: Trust-page metadata MUST mention trust/privacy/security topics and DACH evaluation readiness without overclaiming compliance or certification.

Validation And Follow-Up Boundaries

• FR-025: Later implementation MUST run static scans for forbidden claims and placeholder links across public website source, public assets, and committed generated output when applicable.
• FR-026: Later implementation MUST verify the trust route, homepage trust teaser, and footer/navigation links on desktop and mobile when local preview is available.
• FR-027: Later implementation MUST document deferred detailed permission docs, procurement workflows, or automated claim-guardrail follow-ups as separate specs instead of silently expanding this scope.
• FR-028: Later implementation MUST preserve the root package/workspace contracts, the website package name, and the website port convention unless a separate approved spec changes them.

UI Action Matrix (mandatory when Filament is changed)

N/A - no Filament surface is added or changed.

Key Entities (include if feature involves data)

• Trust Topic: A public trust subject such as hosting posture, AVV/DPA readiness, TOM readiness, data categories, provider permissions, RBAC, auditability, retention, subprocessors, or security contact.
• Claim Status: The bounded public status vocabulary used to mark a trust topic as documented, on request, in preparation, planned, not claimed, or not applicable.
• Data Category: A public-facing description of a type of information Tenantial may handle for governance, evidence, audit, review, or support reasons.
• Permission Posture: A public explanation of why provider access is needed, how read-oriented and write-oriented permissions differ, and how least privilege is applied.
• Document Readiness Item: A public statement describing whether a trust-related document or disclosure artifact is available now, available on request, in preparation, planned, or intentionally not claimed.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: A first-time public visitor can reach the trust surface from the homepage or footer in one click.
• SC-002: A DACH evaluator can find explicit answers or status-marked answers for hosting posture, privacy posture, AVV/DPA/TOM, subprocessors, data categories, provider permissions, RBAC, auditability, retention/export/deletion posture, support access, and security contact within five minutes of landing on the trust page.
• SC-003: 100% of hard trust claims published on the page are either backed by documented verification or replaced with cautious readiness wording.
• SC-004: 0 placeholder links, fake document downloads, fake certifications, fake subprocessors, or fake trust badges appear on the public trust surface.
• SC-005: The provider-permission section clearly distinguishes read-oriented and write-oriented access so a technical reviewer can summarize the difference after one pass.
• SC-006: The trust surface adds no dependency on authenticated platform behavior and requires no apps/platform runtime changes.