<!-- https://svgrid.com/docs/compliance/soc2/ - SvGrid documentation as markdown. Index of every page: https://svgrid.com/llms.txt -->

# SOC 2 posture

sv-grid is a UI library, not a service - so it cannot itself hold a
SOC 2 report. But it can sit inside a SOC 2-audited application, and
the controls below describe the line where the library's
responsibility ends and yours begins.

## TL;DR for procurement

> sv-grid is a client-side JavaScript library shipped as MIT-licensed
> source. It performs no network IO, holds no user data, and has no
> backend. SOC 2 audit scope applies to your hosting and build
> pipeline, not the library. We give you the inputs (SBOM, security
> disclosure policy, deterministic builds) you need to include
> sv-grid in your own SOC 2 report.

## What the library guarantees

| SOC 2 control area    | Library covers                                                  |
| --------------------- | --------------------------------------------------------------- |
| **CC6.1 Logical access** | n/a - no service to log into                                  |
| **CC6.6 Encryption in transit** | n/a - no transit                                       |
| **CC7.1 System operations** | Bundle is deterministic; SHA-256 published per release      |
| **CC8.1 Change management** | Every change ships as a PR with reviews; release notes per version |
| **CC9.2 Vendor management** | One runtime dep in `@svgrid/grid` (`esm-env`, MIT, dependency-free); lazy peer deps in `@svgrid/enterprise` documented in [security](https://svgrid.com/docs/help/security/) |

## What you cover (in your own SOC 2)

| Control area          | Your responsibility                                             |
| --------------------- | --------------------------------------------------------------- |
| Hosting               | Wherever your app is served from (Vercel / Cloudflare / your own infra) |
| User authentication   | Your app's auth layer - sv-grid never sees credentials          |
| Data at rest          | Wherever your data sits BEFORE it reaches the grid              |
| Audit logging         | Wire `onCellValueChange` etc. to your audit pipeline - see [audit log](https://svgrid.com/docs/compliance/audit-log/) |
| Backup / restore      | Your DB - the grid is stateless                                  |
| Incident response     | Your SRE process                                                |

## Inputs we provide to your auditor

1. **MIT licence** - vetted by your legal team once, valid forever
2. **Public source code** - no obfuscation; your auditor can read every line
3. **A shallow dependency tree** - `@svgrid/enterprise`, `@svgrid/grid-wc` and `@svgrid/ui` declare no runtime dependencies; `@svgrid/grid` declares one, `esm-env` (MIT), which has none of its own, so the transitive tree is one package deep. Verify with `npm view @svgrid/grid dependencies`. The two optional peers for Enterprise export (`jszip`, `pdfmake`, both MIT) are listed in [security](https://svgrid.com/docs/help/security/)
4. **Published SBOM** - a CycloneDX 1.6 document per package under [`sbom/`](https://github.com/sv-grid/sv-grid/tree/main/sbom), covering runtime and peer dependencies to full declared depth. Regenerate with `pnpm sbom`; `pnpm sbom:check` fails if it has drifted from the manifests. Satisfies the EU Cyber Resilience Act's machine-readable SBOM expectation
5. **Security disclosure policy** - email `support@jqwidgets.com`, GPG fingerprint published, response SLA documented in [security](https://svgrid.com/docs/help/security/)
6. **Vulnerability history** - every CVE attributed to sv-grid published in the [changelog](https://svgrid.com/docs/changelog/) with disclosure date, fix version, mitigation
7. **npm provenance** - `@svgrid/grid` is published from CI with `--provenance`, so npm records a verifiable link from the tarball back to the building workflow and commit

## Common auditor questions

> *"Is there a SOC 2 report for sv-grid?"*

No - it would be meaningless. There's no service. The library is a
dependency of your application, the same way React or Svelte is. Your
auditor will treat it as a dependency, in scope under CC9.2.

> *"Does sv-grid have access to our data?"*

No. The library runs in the user's browser. Your data is whatever
your app hands to the `<SvGrid data={...}>` prop. We never see it.

> *"Can we self-host the docs?"*

Yes - the entire `docs/` folder is in the repo. Clone, build, host
behind your VPN if your compliance regime requires it. The
[MCP server](https://svgrid.com/docs/help/mcp-server/) runs locally too.

> *"What happens if a CVE is found in sv-grid?"*

Triage within 24h. High-severity patches typically ship within 7
days. Subscribers to the GitHub release notifications get the
release tag the moment we cut it. We backport security fixes to the
last 2 minor versions; see [api-stability](https://svgrid.com/docs/help/api-stability/)
for the support window.

## See also

- [GDPR + data residency](https://svgrid.com/docs/compliance/gdpr/)
- [Security & supply chain](https://svgrid.com/docs/help/security/) - SBOM, signing, dep table
- [Audit log integration](https://svgrid.com/docs/compliance/audit-log/) - turn callbacks into audit events

---

SvGrid is the Svelte 5 data grid (`npm install @svgrid/grid`, MIT). This page: https://svgrid.com/docs/compliance/soc2/ . All docs: https://svgrid.com/llms.txt