Veloce · Security packet · 29 August 2026 · certifiedClaim = false

How this workgroup is secured — and what we will not pretend

Answers to the three enterprise questionnaires, mapped to the real system boundary. Not a SOC 2 report. Not a HIPAA BAA. Not ISO 27001.

How to read the stamps

Every answer is one of four things. If a buyer needs a stamp we do not have, the Order pauses. Inventing a letter is a breach of our own appendix.

In place designed into the current workgroup cut or into /tools as documented.

Gap / host depends on the host volume, a process we have named but not run for a year, or a control we will implement before Type I.

Refused we will not attest this today. SOC 2, HIPAA BAA, FedRAMP, FIPS 140-3 Level 3 HSM, 24/7 SOC, CREST letter, WORM SIEM we do not operate.

N/A as asked the question assumes Postgres-on-Kubernetes-in-three-AZs. We answer the intent against a dual-engine workgroup tenant plus local browser tools.

The three source files asked the same facts three times. Below, each theme is answered once in full. A source map at the end of each domain lists which questionnaire rows it covers.

System boundary

In scope for this packet: one paid workgroup tenant of VeloceDB; the published HTTPS origin; named operator/admin personas; the journal / LSN; customer-held SHOW DIGEST and SHOW INCLUSION; local /tools in the originating browser; product events limited to signup, COMMIT, digest export, verify-pass, source desk.

Out of scope, leftover EXTERNAL, or refused: a live protocol mux on port 1583; native headless CLI binary; DuckDB-Wasm as a second kernel; a Veloce-operated file locker or TURN network; Speak / MCP / agent planes while they are default-off; Azure Confidential Ledger or QLDB compatibility as a certified claim; any trust-company or fiduciary wrap; Customer Data treated as trust property.

Encryption in transit to the Service is TLS on the published origin. Encryption at rest is whatever the host volume provides until we name an application-level scheme we have actually shipped. /tools do not upload the file.

SOC 2 Trust Services Criteria

SOC 2 is an AICPA attestation. A CPA firm examines a described system against the Trust Services Criteria and writes an opinion. It is not a license, not a government certification, and not something a vendor portal “issues” after a questionnaire.

Type I asks whether controls are suitably designed on a date. Type II asks whether those controls also operated across a window — first window often three to six months, renewals six to twelve. Enterprise buyers want Type II. A report covers that window only. After the period ends it ages; a bridge letter is a management letter for about ninety days of gap, not a substitute for a new window.

Security (CC1–CC9) is mandatory in every SOC 2. The common criteria cover control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. That is the whole first letter if we ever sit one.

Four categories are optional and should be added only when the system actually commits to them:

CategoryWhat it would force us to proveOur posture now
Availability (A1)Uptime commitments, capacity, recovery objectives that we publish and meetDo not add until we publish RPO/RTO we can test
Confidentiality (C1)Identification, protection, and disposal of confidential informationPossible later tenant fence + deletion already point here
Processing Integrity (PI1)Complete, accurate, timely, authorized processingJournal + VERIFY analog not a PI1 opinion
Privacy (P1–P8)Notice, choice, collection, use, access, disclosure, quality, monitoring of personal informationDo not add we are not a HIPAA/CCPA product letter

Evidence a Type II auditor samples across the window: access reviews, joiner-mover-leaver tickets, change records, incident log, MFA proof, vulnerability scans, vendor list, termination samples. You cannot backfill the window after the fact. From a standing start, readiness plus a first Type II is commonly four to fifteen months. That is why this packet exists as the honest baseline before an observation window, not instead of one.

SOC 2 compared with ISO 27001 — and where SOC 1 sits

SOC 2ISO/IEC 27001SOC 1
Who writes itCPA firm, AICPA TSCAccredited certification body, ISMS standardCPA firm, controls relevant to a customer’s ICFR
What it isAttestation report on a described systemCertification that an information security management system meets the standardAttestation aimed at financial-statement auditors
AudienceCustomer security reviewersOften procurement + international buyersCustomer’s external audit firm
Time shapeType I date / Type II windowCertificate with surveillance auditsType I / Type II same idea, ICFR scope
Fit for Veloce nowThe letter mid-market will ask first — after we have a windowHeavier management-system lift; not the first plateOnly if a customer books us inside their financial close. Most workgroup tenants are operational, not ICFR. Do not chase SOC 1 to look busy.

ISO 27001 wants a living ISMS: risk methodology, Statement of Applicability, internal audit, management review, corrective action. SOC 2 wants evidence that named controls ran on this system. You can map controls between them; you cannot photocopy one opinion onto the other form. We will not put “ISO-aligned” on the origin until an SoA exists.

Other layers that actually help trust before any letter: this packet; Appendix A on the Order; TLS on the origin; tenant fence; customer-held VERIFY; incident notice to the billing contact; subprocessors on request; a vulnerability mailbox; cyber insurance whose limit sits above the 2× cap ($36,000 on Assist). Those are foundation. They are not SOC 2.

ISO 27001:2022 Annex A — the 93 controls, four themes

Annex A is a catalog. You do not implement all 93 because a brochure said so. You run a risk assessment (clauses 6 and 8 of the standard), pick controls that treat those risks, and write a Statement of Applicability: applicable / not applicable, implemented / planned, pointer to evidence. Without an SoA, “we follow Annex A” is a marketing sentence.

The 2022 revision collapsed the 2013 set (114 controls in 14 domains A.5–A.18) into 93 controls in four themes. Concepts were merged, not thrown away. Eleven controls are new: threat intelligence, cloud services, ICT readiness for continuity, physical monitoring, configuration management, information deletion, data masking, DLP, monitoring activities, web filtering, secure coding. Transition off 2013 ended 31 October 2025; new work starts on 2022.

ThemeIDsCountWhat it actually is
Organizational5.1–5.3737Policy, roles, SoD, assets, access rules, suppliers, cloud use, incident planning, continuity readiness, threat intelligence
People6.1–6.88Screening, employment terms, awareness, discipline, termination, NDA, remote work, event reporting
Physical7.1–7.1414Perimeter, entry, offices, monitoring, environment, clear desk, disposal, utilities — almost entirely the host’s cage
Technological8.1–8.3434Endpoint, access, crypto, logging, monitoring, config, deletion, masking, DLP, vuln, network, secure coding, SDLC

How we will fill an SoA later — not today. Applicable and in place: 5.15 access (named personas + tenant fence), 8.24 cryptography as TLS-on-origin + host volume, 8.10 deletion as 14-day export then tenant delete, 8.15 logging as the product event list, 8.28/8.25 once the SAST workflow in this packet is running. Applicable and gap: 5.1 policy set, 5.3 SoD, 5.7 threat intel, 5.23 cloud-use rules, 5.24 incident plan, 6.1 screening, 6.3 training, 8.8 vuln SLA, 8.16 monitoring. Not applicable as asked: most of theme 7 (we inherit the host’s physical letter), 8.11 masking as a product feature, customer CMEK. Refused to mark implemented: anything that needs a certificate we do not hold.

Clauses 4–10 of the standard (context, leadership, planning, support, operation, performance, improvement) are the ISMS. Annex A is only the menu the SoA points at. A company can fail certification with every technical control green if management review and internal audit never happened.

SAST in CI — the pipeline we implement

Static Application Security Testing reads source without running it. It is Annex A 8.28 secure coding and 8.25 secure development evidence. It is not tenant isolation, not VERIFY, and not a letter. The drop-in workflow is veloce-security/ci/security.yml. How to run it is in SAST-CI.md.

Four jobs on every pull request, plus a Monday cron for advisory drift:

  1. Gitleaks — secrets. Fails the PR once week-1 policy is on. First enable scans full git history (fetch-depth: 0).
  2. Semgrep — pattern SAST with p/security-audit, p/owasp-top-ten, p/javascript, p/python, p/github-actions. SARIF uploaded to GitHub code scanning.
  3. CodeQL — semantic SAST on JavaScript, security-extended.
  4. SCA — npm audit --audit-level=high when a lockfile exists; pip-audit when a Python manifest exists.
  5. Hygiene — fail if a workflow file claims SOC 2 Type II, a HIPAA BAA, FedRAMP authorized, or FIPS 140-3.

Gate ramp: week 0 report-only; week 1 secrets fail; week 2 SAST ERROR/CRITICAL fail; week 3 direct-dep high/critical fail. Pin every uses: line to a commit SHA before calling the workflow production — floating tags are an A.5.21 hole.

Product rules the default packs will not know: no innerHTML from query text or file names in /tools; no eval on customer SQL; no fetch of desk files to a Veloce origin; no live postgres://, sk_live, AKIA, or PEM in tree. Those belong in .semgrep/veloce.yml once the repo hosts this workflow.

Keep Actions history and one SARIF a month. That is the seed of an observation window. A green badge on the marketing origin is refused.

Domain answers (expanded)

1. Cryptographic keys, encryption in transit, encryption at rest

How are master keys generated, what entropy, which KMS/HSM, FIPS 140-2/3 Level 3, envelope encryption, BYOK/CMEK, rotation (90 days / 1 year), split-knowledge recovery, key destruction, keys unique per tenant, software-module validation, crash-dump protection, WAL/backup keys separate, PFS, cipher blacklist, CA for endpoints, mTLS node-to-node, swap/crash-dump leakage, CRIME/BREACH, column-level client-side encryption?

Refused as FIPS-HSM / CMEK / dual-control ceremony A FIPS 140-3 Level 3 HSM is a device with tamper response and a validated module. We do not own one and we will not rent the sentence. Customer-managed keys through an external KMS (CMEK/BYOK) require a key hierarchy we operate and a contract that lets the customer revoke wrapping keys. That product does not exist here. There is no MEK/KEK rotation clock because there is no Veloce KMS. Envelope encryption of rows, split-knowledge key recovery, and per-tenant unique DEKs are the same family of claim: not shipped. Printing “keys unique per tenant” without a DEK table is how these questionnaires get us in trouble later.

Host volume + TLS — confirm on the live terminator before a call Traffic to the published origin is TLS. Annex A 8.24 and SOC 2 CC6.7 live here. The minimum version is whatever the terminator actually rejects; write TLS 1.2+ only after a scan shows 1.0/1.1 are dead. Do not print “TLS 1.3 only” until the config matches. Cipher blacklist, Perfect Forward Secrecy, and certificate issuer plus renewal cycle are host/CDN facts — name the issuer when we know it. Encryption at rest is the host volume setting. Backup snapshots inherit that setting. We will not invent a second key tree “decoupled from production KMS nodes.” WAL/journal encryption is the same host question, not a second product feature. Node-to-node mTLS assumes a cluster mesh we do not sell.

Local tools and customer-held hashes /tools never present a MEK problem. The file does not leave the tab. Desk hop hashes parts with SHA-256 in the browser so the recipient can see a part was not truncated; that is integrity of a part file, not data-at-rest key management. VERIFY is two JSON files the customer holds. None of that is application-level field encryption.

Crash-dump and swap protection for keys, software-module validation (FIPS 140-2 software level), and masking algorithms in non-production are gaps. The operational substitute we will say out loud: do not load a production dump into a second tenant without the customer’s own scrub; we do not offer a masking engine. Deprecated-key destruction is meaningless until a KMS exists. Annex A 8.11 (masking) and 8.10 (deletion) are the SoA rows this domain feeds — deletion we can point at (14-day export then tenant delete); masking we mark not implemented.

Covers exhaustive D1, master 1 and 4, short “Data Encryption.” Annex A 8.24, 8.11, 8.10. SOC 2 CC6.1 / CC6.7.

2. Architecture, isolation, noisy neighbor, AZs, WAF, SQLi, containers

Multi-tenant vs single-tenant, RLS, hard CPU throttles, VPC/micro-segmentation, multi-AZ, private subnet no public IP, WAF/DAM, volume vs OS split, SQLi at driver, UDFs shelling out, temp-table sanitization, Redis cache, Docker/K8s hardening, egress, connection-pool DoS, gVisor, side-channels, partition routing, drop-block wipe, public IPs on instances, network diagram annual review?

Tenant fence — this is the isolation answer A paid SKU is one tenant. Queries and COMMITs are fenced to that tenant. There is no shared demo pool of Customer Data. Isolation is a product invariant, not Postgres row-level security on a shared cluster and not “one VM per logo.” If a query from tenant A can read tenant B, that is a defect, not a multi-tenant design. Application service accounts do not get a wildcard over other tenants because those accounts are not how this engine is sold. Annex A 5.15 and 8.2/8.3 (privileged access / information access restriction) point here.

Not a three-AZ Postgres fleet Multi-AZ automated failover, pod-to-pod mesh, gVisor or Kata sandboxes, hard IOPS quotas against noisy neighbors, side-channel defenses on shared CPU caches, and container runtime hardening of a database microservice mesh are questions written for someone else’s architecture. We will not fill them with invented Kubernetes. High availability is not an Availability TSC commitment on Workgroup, Pain, or Assist. A pinned region is a different Order and fights the no-region COMMIT story if we pretend both are true at once.

Injection and destructive verbs The kernel is our compiler and engine. We do not string-concatenate customer text onto a Postgres driver and call that a query. SHOW verbs are allowlisted. Named HITL (CONFIRM) sits in front of destructive statements. That is the product brake. It is not a WAF, not a DAM appliance inspecting every packet, and not an ORM parameterized-query badge. UDFs that shell out to the host OS are not a supported surface — if that door exists in leftover code it is a defect to close, not a feature to document.

Network edge The published origin must terminate TLS and must not publish a raw engine port (5432/3306 theater, or 1583 as a live mux). WAF and DDoS are host/CDN capabilities: name them when the host bill shows them. A current network diagram, reviewed at least annually, is a Type I artifact we do not have until someone draws the live origin. Connection-pool exhaustion and temp-buffer reuse are engine work; quote no number we have not measured. We do not run Redis/memcached as a Customer Data cache in this SKU — do not describe one.

When a tenant is deleted, the Order gives a 14-day export then delete. That is not a certified wipe of every cloud snapshot the host may still hold. Ask the host how snapshots die; do not crypto-shred a MEK we never issued.

Covers exhaustive D2, master 2, short “Architecture.” Annex A 5.15, 8.2, 8.20–8.23. SOC 2 CC6.1, CC6.6.

3. IAM, MFA, SSO, JIT, break-glass, rotation, IP allowlists

SAML/OIDC, MFA for every admin path, RBAC/ABAC, root locked, 90-day stale revoke, session timeout, least privilege for services, secrets manager rotation, CIDR lock, no shared accounts, JIT elevation, vendor timers, SSH/bastion logs, password complexity, config-parameter ACL, failed-login lockout, quarterly review?

Named personas and ticket-only staff operator and admin are named in-product. A shared “root everyone knows” is not the model. Veloce staff touch a tenant only for a ticket the customer opened, or a legal demand. That is the least-privilege story we can defend today. Shared generic service accounts across modules are refused as a practice even if leftover code still has one — find it and kill it. Annex A 5.15, 5.16, 5.18; SOC 2 CC6.1–CC6.3.

SSO, MFA, reviews, rotation — write them or keep C-22 leftover SAML/OIDC and MFA are leftover unless that tenant has them live. Ticking SAML on a SIG when the login page is email-and-password is a false statement. Password complexity, lockout after failures, idle session timeout, quarterly access review, and 90-day inactivity disable are the Type I minimum. They are calendars and config, not a vendor logo. Just-in-time elevation with an identity-governance tool is not shipped. Secrets-manager rotation of app credentials is a gap. IP allowlisting is a host control when we turn it on — not before. Vendor and contractor access gets a named end date on the ticket; there is no standing contractor role.

Bastion farm and dual-control break-glass as if they exist We will not describe SSH to “database nodes,” Session Manager, or a break-glass root in a vault with split knowledge until that ceremony is written, practiced, and logged. Inventing it for a SIG is how you fail the first Type I sample.

Covers exhaustive D3, master 3, short “Authentication.”

4. Logging, SIEM, WORM, every-query identity

Unalterable DDL/DCL logs, every query with IP and user-agent, real-time SIEM, DBA cannot delete logs, WORM, retention tiers, SQLi failure monitoring, anomaly downloads, scrubbed stack traces, log-pipeline testing, config-change alerts, success and failure auth, log encryption, correlation through connection pools?

Product events and HITL We record operating events needed to run the Service: signup, COMMIT, digest export, verify-pass, source desk. SHOW HEALTH is product-level. Destructive verbs sit behind named CONFIRM. The journal / LSN is the mutation record the customer can digest. That is Annex A 8.15 as far as the product goes. It is not Splunk, not WORM object-lock, and not “every SELECT, every row.”

Auth logs and no secrets in traces — do these before Type I Successful and failed authentication belong in the event list. Schema-shaping statements (the analog of DDL/DCL) should be attributable to a named operator. Stack traces must not print connection strings or tokens — that is an engineering rule, enforced also by the SAST hygiene job once it is on. A monthly export of event volume (so we notice silence) is the poor-person’s “log pipeline test.”

WORM SIEM of every query with signed chain of custody Central SIEM, immutable volumes, cryptographic batch signing, real-time shipping with measured latency, hot/warm/cold retention tiers, and correlation from an API request through a connection pool to a row-level read are a different product. If a buyer needs that, pause. Annex A 8.16 monitoring is a planned SoA row, not an implemented one.

Covers exhaustive D4, master 5, short “Logging.”

5. Vulnerability, patching, CIS, pen test, bug bounty, SAST/DAST

14-day critical SLA, CIS Benchmarks on hosts, scan cadence, annual CREST pen test with clean letter, bounty program, default accounts removed, staging-before-prod patches, AIDE/tripwire, SAST/SCA in CI, live kernel patch, EOL engine watch, disable extra daemons, extension allowlist, firmware/hypervisor, DAST on admin APIs?

Cadence + the SAST pipeline in this packet Annex A 8.8 and 8.25–8.28 live here. The drop-in workflow (Gitleaks, Semgrep, CodeQL, npm audit / pip-audit, hygiene grep) is how we implement SAST in CI. It becomes “in place” the week it is merged and failing secrets on PRs — not the week we wrote the YAML. Add: a written patch SLA (critical host/engine aimed inside 14 days, high 30, medium next window); security@ mailbox; no default sample databases on the origin; unused engine surfaces left off; staging before production written down when it actually runs; Dependabot or Renovate on direct pins.

CREST clean letter, paid public bounty, CIS-fleet attestation, tripwire-on-every-node, kernel live-patch Independent pen test is a future purchase. DAST only against surfaces we publish. Firmware and hypervisor patching belong to the host. Third-party extensions loaded into the engine are an allowlist problem — default deny if we do not have one yet.

Covers exhaustive D5, master 6–7, short “Vulnerability.” See SAST-CI.md.

6. Disaster recovery, immutability, RPO/RTO, split-brain

RPO/RTO numbers, object-lock backups, restore-test frequency, geo-replication, automated regional failover, PITR continuity, separate backup ACLs, media wipe, BCP for total cloud loss, replication lag vs RPO, purge vs contract, multi-region write, executive-signed drill results, consensus split-brain?

Published RPO/RTO and multi-region active-active We have not published numbers we can test. Inventing “RPO 5 minutes / RTO 1 hour / automated us-east failover” would be a lie. PITR as a certified control is leftover. Customer-held VERIFY plus a data export is how a tenant proves what it COMMITted; that is not a regional DR product.

Backup of the tenant Host snapshots, if the host takes them, plus the 14-day export on termination. Restoration drills, immutable object-lock, air-gapped accounts, and executive-signed tabletop results are work items, not ticks. Split-brain in a consensus cluster is N/A as asked: we do not sell Raft-as-a-region.

Covers exhaustive D6, master 8, short “Backup.”

7. Incident response, SOC, insurance, forensics, 24/7

Breach-notice SLA, 24/7 SOC, ransomware runbooks, tabletop cadence, background checks, training, cyber insurance limit, threat-intel firewall feeds, forensic imaging, 24-hour offboarding, schema peer review, support export controls, no developer prod access, supply-chain for libraries, post-mortems?

Notice Unauthorized access to Customer Data in the tenant: notify the billing contact without unreasonable delay. That is on the Order. It is not a statutory “72-hour GDPR clock” we pretend to be bound by for every tenant worldwide.

24/7/365 SOC, retained CREST forensics firm, threat-intel-to-WAF feed as a product Workgroup and Pain SKUs are email hours. Assist is a named human for ninety days. Do not sell a SOC.

Human governance Background checks for people who can touch production, security training, 24-hour offboarding of access, peer review on schema-impacting changes, a written ransomware/exfil runbook, tabletop once a year, post-mortem on high-severity events, cyber insurance with a limit above the 2× Assist cap ($36,000). Those are foundation tasks. Insurance coverage threshold is a broker fact to fill — do not invent $5M.

Covers exhaustive D7, master 9–10 partial, short “Incident.”

8. HR and physical data center

Criminal screening, phishing sims, 24-hour revoke, contractor NDAs, SOC 2/ISO of the colocation cage, mantraps, biometrics, CCTV, clean desk, laptop encryption, MDM, SoD no single engineer drop-database-and-ship-code, insider-threat UEBA, whistleblowing, media disposal?

People process NDA for anyone with tenant access, offboarding inside 24 hours as a written rule, encrypted laptops for operators, no production data on personal machines. Screening and phishing cadence should be written before Type I.

We will not reprint a colocation provider’s SOC 2 as if it were ours Physical mantraps and biometric cages belong to the host. Ask the host; attach their letter if a buyer needs physical. Separation of duties “no one person can ship code and drop the tenant” is a process to design (two-person release or HITL on PURGE) — name it when it runs.

Covers master 10, short vendor/HR rows.

9. Supply chain and subprocessors

SBOM, SCA, vendor intake, subprocessor SOC 2 collection, flow-down breach clauses, pinned dependencies, image review, consultant time-boxes, abandoned-lib watch, typosquat, audit rights on vendors, backup vendors?

List on request Hosting and email subprocessors are named when asked. /tools have none. A new subprocessor that will see Customer Data requires notice.

SBOM / SCA / pin Generate an SBOM for what we ship; pin direct dependencies; watch CVEs on those pins. Vendor intake for anything that will touch a tenant. We do not have a contractual right to audit AWS-class hosts; we collect their attestations instead of pretending we can inspect us-east-1.

Covers master 11.

10. Regulatory letters the questionnaires want ticked

GDPR mappings, HIPAA BAA, CCPA “do not sell,” FedRAMP Moderate/High, NIST 800-53 / ISO SoA, cross-border, residency pin, PIPEDA, Australia Privacy Act, SEC 17a-4, DPO named, conflict-of-laws engine?

HIPAA BAA, FedRAMP, SEC 17a-4 WORM, “GDPR-certified,” ISO certificate We are not a covered entity/business associate for a BAA we have not signed. We are not in a FedRAMP boundary. We do not sell a 17a-4 archive. Privacy TSC and a DPO office are not this SKU. Data residency as a customer-configured region pin contradicts the no-region COMMIT story — a pinned region is a different Order.

Deletion / export 14-day export then tenant delete. Customer owns the data. We do not sell data. CCPA “sale” is not our model. Cross-border is whatever the named host’s region is, disclosed as a subprocessor fact, not a sovereignty product.

Covers master 12 and 14, plus HIPAA rows everywhere.

11. Network defense extras (DDoS, WAF, IDS, SSRF, honeytokens)

Edge DDoS and WAF are host/CDN capabilities if enabled. IDS/IPS on a storage fabric, encrypted-traffic inspection without breaking TLS, and honeytokens inside the engine are not shipped. SSRF and unexpected egress from “cluster compute” are N/A as a Kubernetes story; still block the origin from arbitrary egress where the host allows it.

Covers master 13, short architecture WAF/DDoS/IDS rows.

12. Privacy, retention, crypto-shred

Export then delete On termination, export window then delete. Telemetry is the short event list, not dump contents. Support does not get a standing export path; staff access is ticket-only.

Crypto-shred by destroying a per-tenant MEK we do not issue Hard-delete verification across geo-replicas we do not run. Right-to-be-forgotten without breaking “global schema indexes” is a Postgres-SaaS question; we delete the tenant.

Additional questions we added — because buyers will

What is the exact legal entity on the Order?

The Delaware operating company. A Delaware trust that owns equity is not a party and is not a fiduciary to the customer. Fill the legal name before the first SIG goes out.

Is Veloce a Delaware trust company under Title 5?

The MSA refuses the fiduciary wrap. If an OSBC or OCC charter exists elsewhere in the group, VeloceDB is not sold off that charter. 8 Del. C. § 395 restricts advertising as a trust company. Customer Data is not trust property.

What is the liability cap if this packet is wrong?

Table 1 / Table 2 on the MSA: 1× fees ($3,600 / $8,400 / $18,000) ordinary; 2× for unauthorized tenant access caused by us ($7,200 / $16,800 / $36,000). Free /tools with no Order = $0 money damages.

Do you store SAM inventories or MAP toolkit dumps?

No. The meter is local. Raw scans are refused attachments.

Is VERIFY an immutable ledger attestation?

No. It is two JSON files the customer holds. Not QLDB, not Raft, not Azure Confidential Ledger.

Can we complete a SIG Lite in lieu of this packet?

This packet plus Appendix A is the SIG. A longer CAIQ that demands C-23/C-25 still pauses.

When will Type I start?

After the foundation list below has produced at least one quarter of access reviews, an incident log with a beginning, a named host + TLS config we can show, and a vulnerability mailbox that has been answered. Not this 90-day bookings quarter.

Foundation before a Type I — the work, not the badge

  1. Print the Delaware entity name and the host/email subprocessors on a one-page list.
  2. Confirm TLS minimum on the live origin; turn off raw engine ports.
  3. Write and run a monthly access review (who can open which tenant).
  4. Write joiner-mover-leaver including 24-hour revoke.
  5. Open a security@ mailbox and a one-page vuln intake.
  6. Start an incident log even if the first line is “none.”
  7. Buy cyber insurance and write the limit next to the $36,000 2× cap.
  8. NDA + laptop encryption for anyone who can touch production.
  9. Pin dependencies and generate an SBOM for the shipped tree.
  10. Merge ci/security.yml, ramp the gates in SAST-CI.md, keep one SARIF a month.
  11. Restoration drill of a tenant export — once, documented.
  12. Decide MFA/SSO for admin and ship it or keep C-22 leftover.
  13. Then, and only then, pick a CPA and a Security-only Type I date. Type II window starts after Type I if the date is clean. ISO SoA is a later plate.

Until those twelve exist, this page is the security story. It is already more useful than a fake 87/100 dashboard.