Trust at Shards

Where your data lives

Stored in the EU: Microsoft Azure, Sweden Central. Traffic to and from Vittnor passes through Cloudflare's network, which can handle it outside the EU.

Vittnor runs multi-tenant today. Single-tenant deployment is a future option for buyers with stricter requirements — if that's a hard requirement on your side, raise it and we'll tell you where it sits on the roadmap. Where your data is stored doesn't change either way.

Tenant isolation

Every customer's data is partitioned by BuyerOrgId. The application layer enforces tenant boundaries on every read and write — clients never decide tenant context on writes; the server resolves it from authenticated identity. Row-level security in the database is enabled as a defence-in-depth backstop.

In practice: the partition is enforced server-side on every read and write, with row-level security as a database backstop — Customer A's evidence, decisions, and sub-processor lists cannot be queried or exported by Customer B.

How evidence is handled

Short-lived SAS tokens. Evidence files are accessed via signed URLs that expire within minutes. No permanent file links.
Immutable by path. Once an evidence file is uploaded, the path it lives at never changes. Replacements get new paths and new hashes.
Hash-anchored. Every evidence artefact carries a SHA-256 hash that travels with it through every reuse, decision, and export.
Audit log. Your organisation's audit log records who did what — uploads, reviews and decisions.

We don't use customer data to train AI models.

What that looks like in the product

Buyer-side evidence review — requirement statuses, a versioned supplier submission, and an approve/reject decision panel with reviewer attribution — **Attributed submissions.** Every artefact arrives versioned and attributed — who submitted it, when it was due, and which requirement it answers.Humans approve. The decision panel is the audit event. Every approval, rejection, and resubmission is captured immutably.

Encryption

In transit: TLS 1.2+ for all client connections; TLS-only enforced at the edge.
At rest: Azure platform-managed encryption (AES-256) for all storage tiers — database, blob storage, key vault.
Key management: Azure Key Vault, in the EU. Key rotation per Microsoft platform defaults.

Authentication and access

Identity: Microsoft Entra ID for internal accounts; customer sign-in runs on Microsoft Entra External ID. Workforce SSO for buyer organisations is planned as an enterprise option at V1.
MFA: required for all internal accounts. Strongly recommended for customer accounts; enforced where the buyer organisation requires it.
Role-based access: three roles per organisation — Admin and Reviewer for the people who work on your suppliers, Member for the people who only answer your customers' requests.
Session handling: short-lived bearer tokens with refresh on activity. Idle timeout enforced server-side.
Audit: all authentication events (login, MFA challenge, role change, permission grant) emit audit events.

Sub-processors

The third parties that process customer evidence as part of operating Vittnor:

Microsoft Azure (Sweden Central, in the EU) — hosting, database, evidence file storage, secrets, logs and monitoring
Microsoft Entra ID and Microsoft Graph — sign-in, guest accounts, invitation emails
Cloudflare — DNS and network protection for all traffic to and from Vittnor, and the bot check on registration

The sub-processor list is updated whenever a sub-processor is added or removed. Customers are notified at least 30 days in advance, in Vittnor, with the right to object.

Third parties that load on this marketing website (analytics, the contact-page map embed) are listed separately under About this website below — they are out of scope for the product's sub-processor agreement because no customer evidence flows through them.

Data retention and deletion

Customer-controlled retention; we don't hold data longer than the engagement requires. The defaults that ship today:

During the engagement: evidence and decisions are retained for the duration of the contract, with the immutability guarantees described above.
Export: on request, free of charge, in a machine-readable format.
When you leave: at least 30 days to take your data, then erasure, confirmed in writing on request.
Sub-processor propagation: deletion requests propagate to sub-processors with deletion confirmation returned within their own contractual SLAs (Microsoft platform-default deletion timelines for Azure storage tiers).

SLA stance

During the pilot: no contractual uptime SLA. The platform runs on Azure's underlying availability guarantees; we monitor and respond, but we don't commit to a percentage we can't back with operations team coverage today.

From production-ready (Q4 2026): Marketplace-grade SLA commitments — uptime percentage, incident-response time, status-page-driven communication — codified in the production agreement. The exact targets are being calibrated against real pilot-era operational data; we will publish them with the production-ready release.

We don't commit to a number we can't hit. The honest stance during pilot is "best-effort, fast response, no SLA penalty" rather than a fabricated 99.9% we have no way to defend.

Frameworks we align to

Alignment is not certification. The list below names the frameworks whose control sets shape how we built the platform — they inform what evidence we produce, how we audit, and what artefacts the platform expects from suppliers. Where we hold an actual certification it will appear under the compliance posture section below.

Directive (EU) 2022/2555 (NIS2) — Article 21(2)(d) is the load-bearing reference for the supplier-assurance model Vittnor implements.
ENISA Technical Implementation Guidance v1.0 — the practitioner reference for what appropriate measures look like in practice, particularly for the supply-chain control set.
EU ICT Supply Chain Security Toolbox — the NIS Cooperation Group's coordinated Member State guidance on assessing and managing ICT supply-chain risk.
ISO 27001 (alignment, not certification) — the Annex A supplier-assurance controls (A.5.19–A.5.22) are a design reference for Vittnor's assessment model. Certification is on the roadmap; see the compliance posture below.
GDPR Article 28 — the processor-controller obligations that shape our DPA template and sub-processor handling.

Microsoft Partner and ISV programme

Shards is a Microsoft Partner. Vittnor is being prepared for the Microsoft Marketplace via the Microsoft ISV programme — the architecture is reviewed against Microsoft's ISV well-architected baseline, and the marketplace listing will follow at production-ready release.

In practical terms: the choice of Microsoft Azure as the platform isn't just hosting. It carries through to identity (Entra ID) and procurement (Marketplace billing). It also means we inherit Azure's platform-level controls; everything above that layer is ours — that's what the SOC 2 work covers.

Compliance posture

We're working toward:

SOC 2 Type I — readiness work in progress, target: H2 2027
ISO 27001 — preparation in progress, certification target: H1 2028

When the audits land, this page will say so. Until then, the technical and organisational measures already in place are described here and in our DPA template.

Vulnerability disclosure

If you've found a security issue, please email security@shardscybersecurity.io. Security reports are read first and answered quickly.

See our security.txt for the canonical disclosure address.

Status

A real-time public status page is on the roadmap. Until then, incident updates go to affected customers by email; if you suspect an outage, write to security@shardscybersecurity.io.

Data Processing Agreement

A standard GDPR Article 28-compliant DPA is available — see our DPA template page for what it covers and how to get a copy.

Different scope

Everything above describes how Vittnor hosts and processes customer evidence. The section below describes how this marketing website operates — the third parties that load when you visit shardscybersecurity.io, separate from the product's sub-processors.

About this website (shardscybersecurity.io)

The marketing site is a static Next.js build hosted on Cloudflare Workers. Three third-party services can load on top of the static content — one sitewide for visitors outside the EU, the EEA, Switzerland and the UK, two only on /contact and only after you click to load them:

Cloudflare Web Analytics — a cookieless beacon (static.cloudflareinsights.com/beacon.min.js) that counts page views per route. Cloudflare leaves it out of pages served from its data centres in the EU, the EEA, Switzerland and the UK. For other visitors it sets no cookies and does no fingerprinting, and Cloudflare discards the IP address at its edge without storing it.
Google Maps embed — only on the /contact page, behind a “Load map” button. No request reaches Google until you click; once loaded, the embed is subject to Google's privacy policy.
Microsoft Bookings calendar — only on /contact, behind a “Load the booking calendar” button. No request reaches Microsoft until you click; once loaded, the calendar is subject to Microsoft's privacy statement.

All three are out-of-scope for the product's sub-processor agreement (no customer evidence flows through them). The cookie notice you may have seen on first visit is informational — this site sets no cookies of its own (Cloudflare's security check sets one only if it challenges a visitor), and you can verify that in your browser's developer tools. The full disclosure is on /cookies.

Site hosting (Cloudflare Workers) and DNS (Cloudflare) are infrastructure-level providers for the marketing site itself; they don't process product data and aren't sub-processors in the GDPR Article 28 sense.

Trust at Shards.