Trust at Shards.

Where your data lives

EU-only. Microsoft Azure, North Europe (Ireland) and West Europe (Netherlands) regions. No customer data leaves the EU under any default configuration.

For buyers with stricter requirements, single-tenant deployments are available in the same regions on request. The deployment model doesn't change the EU-only commitment.

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, this means Customer A's evidence, decisions, and sub-processor lists cannot be queried, exported, or accidentally surfaced to Customer B. The architecture makes cross-tenant leakage a structural impossibility, not a control we trust to behave.

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.
• Malware scanning. Every upload is scanned before it's accessible to reviewers.
• Append-only audit log. Every action — uploads, reviews, decisions, exports, exceptions — emits an audit event that cannot be modified after the fact.

What that looks like in the product

Preview

Encryption

• In transit: TLS 1.2+ for all client connections; TLS-only enforced at the edge. HSTS preload-eligible configuration.
• At rest: Azure platform-managed encryption (AES-256) for all storage tiers — database, blob storage, key vault. Single-tenant deployments can use customer-managed keys (CMK) from a customer-controlled Azure Key Vault on request.
• Key management: Azure Key Vault, EU regions only. Key rotation per Microsoft platform defaults; customer-managed key rotation under customer control where CMK is in use.

Authentication and access

• Identity: Microsoft Entra ID (Azure AD) for both internal and customer-side authentication. SSO integration available for buyer organisations on request.
• MFA: required for all internal accounts. Strongly recommended for customer accounts; enforced where the buyer organisation requires it.
• Role-based access: three primary roles per buyer tenant — Reviewer, Approver, Administrator. Each role's permission set is documented in the platform admin guide.
• 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.

How AI is used (and not used)

AI in the product is assist-only and citation-bound:

• Hosted in the EU. Azure OpenAI, EU region. Customer evidence never crosses tenant boundaries or third-party model providers.
• Retrieval-grounded. AI suggestions are grounded in your evidence, with mandatory citations to specific source artefacts. No citation, no claim.
• Human-approved. AI never approves a supplier, closes a review, or modifies decision state automatically. Every AI suggestion is a draft for a human to accept, modify, or reject.
• Auditable. Every AI interaction emits an audit event with model version, evidence set, and timestamp.

We don't train models on customer data. We don't share evidence with third-party AI services. We don't auto-approve.

Sub-processors

The third parties that process customer evidence as part of operating the Supply Chain Assurance product:

• Microsoft Azure (EU regions only) — hosting, database, blob storage, AI inference via Azure OpenAI
• Resend (EU region) — transactional email delivery

The sub-processor list is updated whenever a sub-processor is added or removed. Customers are notified in advance of additions, 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.
• Pilot end-state: 30-day grace period after pilot termination during which a complete export is available (JSON for the data, signed PDF dossiers for human-readable evidence packs). After the grace period, complete deletion proceeds.
• Deletion certificate: on completion of the deletion run, you receive a signed deletion certificate that names what was deleted, when, and from which storage tiers (database, blob storage, backups).
• 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.

Brand voice §10 — 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.

• NIS2 Directive (2022/2555) — Article 21(2)(d) is the load-bearing reference for the supplier-assurance model the platform 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.
• NIS Cooperation Group ICT Supply Chain Toolbox — coordinated EU Member State guidance on assessing and managing ICT supply-chain risk.
• ISO 27001 (alignment, not certification) — the platform's control mappings cover the ISO 27001 Annex A controls relevant to supplier assurance. 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. The platform 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), AI inference (Azure OpenAI), and procurement (Marketplace billing). It also means the same security baseline a Microsoft-procuring buyer is familiar with from other ISV products applies here — the controls we build on are the controls Microsoft documents and audits at the platform level.

Compliance posture

We're working toward:

• SOC 2 Type I — readiness work in progress, target completion within 12 months
• ISO 27001 — preparation in progress, certification target within 18 months

We don't claim certifications we don't have. When the audits land, this page will say so. We'd rather be honest about being early than overclaim.

In the meantime, we're transparent about the technical and organisational measures already in place — see this page and our DPA template for the full picture.

Vulnerability disclosure

If you've found a security issue, please email security@shardscybersecurity.io. We respond within one business day.

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.

About this website (shardscybersecurity.io)

The marketing site is a static Next.js build hosted on Cloudflare Pages. Two third-party services load on top of the static content:

• Cloudflare Web Analytics — a cookieless beacon (static.cloudflareinsights.com/beacon.min.js) that counts page views per route. No cookies, no fingerprinting, no personal data. Why no cookie banner is needed for it: GDPR-friendly by design.
• Google Maps embed — only on the /contact page, used for the Bratislava office location map. Google Maps loads from Google's domains and is subject to Google's privacy policy; we do not pass any user data to it beyond what the embed's map controls themselves transmit.

Both are out-of-scope for the product's sub-processor agreement (no customer evidence flows through them). The cookie banner you may have seen on first visit relates to the cookie disclosure on /cookies which goes into more detail.

Site hosting (Cloudflare Pages) 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.