Engineered defense for the systems we build.
Security postures decay. Ours rolls. Keys rotate on cadence, identities re-issue against scope changes, tenants can be cryptographically erased on demand, deploys roll without opening a gap. This is Rollable Security, a posture engineered for rotation rather than against it. The architectural spine is zero-trust per NIST SP 800-207, with a Layer Zero policy decision point gating every interior layer.
Audit is not an incident-response artifact. Audit is the prevention model. The third-party auditor who walks in every six months at a regulated customer is checking whether the process makes unauthorized change impossible, not whether unauthorized change has occurred. Every write to financial data carries an OCSF event class (3001 Authentication, 3002 Authorize Session, 6003 API Activity), a business_reason, an evidence_hash, and a parent_event_id. Even authorized users follow the documented process; the process IS the evidence.
SOC 2, ISO 27001:2022, GDPR, HIPAA, PCI-DSS v4.0 are not certifications we add at the end. They are the control framework we build inside. CC6.1 through CC7.5 for the access and audit surfaces. A.5.15 through A.8.30 for identity, logging, and cryptography. Art. 17 and Art. 30 for erasure and records of processing. §164.312 for the technical safeguards. Cryptography is named: AES-256-GCM at rest with envelope encryption via KMS, TLS 1.3 with mTLS for service-to-service, HKDF-SHA-256 for key derivation. Compliance is a checkable claim, not a marketing line.
Every regulated customer must demonstrate all four to their third-party auditor. They are not interchangeable. Each answers a different question, cites a different standard, and produces a different artifact.
Who did what, when, with what permission, for what business reason.
Row-level audit logs of every change, attributable to a human or service identity. No shared accounts, no anonymous writes, no ambiguity about which principal touched which record.
Where data flowed across services after a transaction touched the system.
Bi-directional. Forward from transaction to data state across all downstream services. Reverse from a changed data state back to the originating event.
Access events captured even when no data changes, including read-only sessions.
Source IP, timestamp, protocol, identity, role, and consent grant per service-to-service call. A login that read nothing is still a logged event.
The artifact produced by the three above, structured for third-party handover.
Generated at the point of action with business_reason and evidence_hash. Verified by inventory and chain-of-custody at audit time. Classes 3001, 3002, 3005, 6003, 6004 with Insignia extensions.
SAST and DAST in CI on every PR, dependency audits with signed provenance, container images verified at admission. The build pipeline is a defense surface, not just a delivery one.
STRIDE at architecture review, attack-tree analysis at design time, PASTA where the regulatory surface warrants it. Threat names become the audit log schema; mitigations ship with the feature and emit OCSF events on every triggering condition.
IAM scoped to the least privilege the workload actually needs, secrets in KMS-backed stores, network posture audited continuously. Infrastructure assumes breach so the application doesn't have to.
RBAC enforced at every boundary, MFA on every administrative path, append-only audit logs cryptographically chained. Every privileged action attributable to a human or a service identity, never to a shared account.
Playbooks rehearsed before they're needed, tabletops on a quarterly cadence, simulated breaches against the production-equivalent. When an advisory drops, the response is muscle memory.
LLMs in production need their own threat model. Prompt isolation, tool-permission scoping, deterministic gates over load-bearing outputs, runtime auditing of every model call. Training-data lineage uses Multi-Key Encryption with cryptographic erasure for contributor takedowns; consent grants gate every pipeline action that touches PII. The agent's confused-deputy property is the new attack surface.
The third-party auditor who walks in every six months at a regulated customer is not looking for evidence that something went wrong. They are verifying that the process makes unauthorized change impossible to make silently, and that authorized change leaves a complete, tamper-evident trail. The audit ledger does both jobs at once. Generation captures the trail at the point of action. Verification hands it over in a form the auditor can ingest natively.
Capture points are wired into the application, the service mesh, and the data layer. Every write to a FinancialRecord resource emits an OCSF Class 6003 API Activity event. Every authentication or privilege grant emits Class 3001 or 3002. Every config change emits Class 3005. The mesh layer adds source IP, session identity, and trace-correlation IDs without the application needing to know. The data layer adds the row-level diff and pre-image hash on writes that touch regulated tables.
The canonical payload extends OCSF v1.2.0 with four mandatory Insignia fields: business_reason (free-text justification, pre-filled from change tickets where available), evidence_hash (SHA-256 of the canonical payload, signed by the ledger appliance per NIST SP 800-92 §5.3), parent_event_id (causality link for forward and reverse traceability), and consent_grant_id (Layer Zero policy decision point reference when personal data is touched). Storage is append-only, with a signed Merkle root over each retention window. Tamper-evidence is mathematical, not procedural.
Free-text field justifying the action. Pre-filled from change-ticket integration where available. Empty value rejected at write-time. This is the field the auditor reads first.
The handover pack is generated automatically at audit period close. Every artifact has a stable schema (OCSF NDJSON for the log archive, CSV for the access matrix, signed PDFs for cross-referenced evidence chains, structured JSON for the consent ledger) and ingests cleanly into the major audit tooling (Workiva, AuditBoard, ServiceNow GRC) without bespoke mappers. The auditor's first session is a sit-down with a stack of indexed artifacts, not a chase across four systems and three discovery calls.
Tamper-evidence is verifiable end-to-end. The signed Merkle root over the audit log archive is cross-referenced by every evidence_hash in the body. Any post-write modification breaks the chain and the verification cycle detects it. The auditor can rebuild the chain independently from the export. We do not ask them to trust our copy.
What the third-party auditor receives in the first session. Pre-staged. Indexed. Cross-referenced. Replaces four discovery calls.
Every system component in scope, with owner, classification, residency, and last-validated timestamp.
Identity × resource × permission. Every entitlement at audit cutoff, with granting policy reference and last-review date.
Append-only ledger covering the audit period. Tamper-evident via signed Merkle root. Per-event evidence_hash chain verifiable end-to-end.
For each material finding referenced in the auditor's worksheet, the parent_event chain from triggering event to final disposition.
Every key rotation in the audit period, with timestamp, triggering event, and prior-key destruction confirmation.
Every consent grant, revocation, and re-grant in the period. Grants linked to the actions they authorized via consent_grant_id.
Every privilege escalation, break-glass invocation, and admin action in the period, with business_reason and reviewer attestation.
Every security incident detected in the period, with timeline, scope, remediation, and post-incident review.
Row-level security answers a single question: is this principal allowed to touch this record. It is enforced at the data layer and it returns yes or no. That is necessary, but it is not audit. Audit answers a different question. Even though this principal was allowed, did they follow the documented process. Can the causality chain be rebuilt end-to-end. Can we prove the record has not been silently altered since the action.
The distinction matters because the failure modes are different. Row-level security failure is unauthorized access. Audit failure is undetectable change by an authorized actor, or detectable change with no chain back to the why. The regulated customer cares more about the latter. The former is a moat. The latter is the floor of the moat.
Even super-admin and DBA principals cannot self-escalate to change financial data without going through the documented process. Break-glass invocations are themselves OCSF Class 3002 events with business_reason, reviewer attestation, and an automatic post-action notification to the audit committee. Authorization is not an audit substitute. The process is.
The compliance question is not abstract. It is countable. How many interfaces are exposed today, which ones, on what protocols, behind what authentication, encrypted how, audited when. Inside Insignia, this answer is a generated report against a single source of truth, not a slide deck assembled the week before the audit.
The perimeter posture is zero-trust per NIST SP 800-207. There is no soft interior. Every service-to-service call passes through mTLS with workload-identity verification. Internal subnets enforce the same auth model as the public edge; the difference is reachability, not trust. East-west traffic is observed at the mesh layer, with per-call telemetry feeding the same audit ledger that records identity events.
The firewall posture follows NIST SP 800-41 and CSA Cloud Controls Matrix v4 IVS-01 through IVS-09 (Infrastructure and Virtualization Security). Default-deny at every boundary. Allowlists, not blocklists. IP exposure is tracked as a count and a delta against the prior audit period; any new exposure carries a documented justification linked to the change ticket and a sunset date. Egress allowlists are workload-scoped. No unbounded internet from compute.
| ID | Endpoint | Exposure |
|---|---|---|
| IF-001 | api.example.com/v2 HTTPS/2 OAuth 2.1 + mTLS TLS 1.3 · 2026-04-12 | Public |
| IF-002 | admin.internal.example.com HTTPS/2 OIDC + AAL3 + SCIM TLS 1.3 mTLS · 2026-04-12 | VPN only |
| IF-003 | events.example.com (webhook) HTTPS HMAC-SHA-256 signature TLS 1.3 · 2026-03-30 | Public · IP allowlist |
| IF-004 | sftp.example.com SFTP SSH key + IP allowlist SSH-2 (chacha20-poly1305) · 2026-04-05 | Public · IP allowlist |
| IF-005 | db-replica.internal PostgreSQL wire Cert auth + ABAC TLS 1.3 mTLS · 2026-04-12 | Private subnet |
| IF-006 | kms.regional KMS API Workload identity + IAM TLS 1.3 mTLS · 2026-04-12 | Service mesh only |
Reach internal services without a valid credential, often by forging a token or exploiting a weak verification path at the edge.
The KMS holds three independent key tiers per encrypted item: a user-level key derived per-principal via HKDF-SHA-256, an application-level key stored in the KMS and rotated quarterly minimum, and a tenant-level key stored in the KMS and rotated on boundary events. Cryptography is named: AES-256-GCM at rest with envelope encryption, TLS 1.3 with mTLS for service-to-service, RFC 5649 AES key wrap with padding for cross-tier wrapping.
The three-tier structure exists because deletion is the wrong primitive in a regulated data pipeline. By the time a user invokes GDPR Art. 17, derived data has already fanned out into seven or more downstream systems with independent retention. Chasing the data is incomplete by definition. Removing the user-level key is complete by construction, and audit-ledger-verifiable in one operation.
The same primitive serves tenant separation. When a customer organization is acquired and the new owner needs old-owner visibility removed, the tenant-level key rotates and prior ciphertext becomes inert without touching application code. Reference framework: NIST SP 800-57 Part 1 (Recommendation for Key Management), NIST SP 800-88 Rev. 1 §4.7 (Cryptographic Erasure).
| Tier | Key | Cadence |
|---|---|---|
| T1 | User-level key HKDF-SHA-256 Trigger · Identity event | Per-principal, re-derived on scope change NIST SP 800-57 Part 1 §6.2 |
| T2 | Application-level key AES-256-GCM via KMS envelope Trigger · Time-based | Quarterly minimum, automated rotation NIST SP 800-57 Part 1 §5.5 |
| T3 | Tenant-level key AES-256-GCM via KMS envelope · RFC 5649 key wrap Trigger · Boundary event | On acquisition, divestiture, or deletion request NIST SP 800-57 Part 1 §8.3 |
A user-controlled photo enters the CRM. Within the same minute, the pipeline derives a face vector, an EXIF block, a perceptual hash, an inference fingerprint, an audit-ledger entry, a backup snapshot, and a telemetry trace. Seven downstream artifacts now exist, each containing some shape of the original.
Engagement with , EU SaaS principal. GDPR Art. 17 program covering 47 downstream data systems. User-level cryptographic erasure with a 60-second cascade SLA per request. Audit ledger retains the erasure events themselves per NIST SP 800-92 §5.1, with `parent_event_id` linking each erasure back to the original ingest event.
Hover or focus the bar to reveal · client identity protected
Layer Zero sits outside the onion. Before any request reaches the perimeter, network, application, or data layer, it passes through three independent checks that resolve to a single allow-or-deny decision. Identity answers who. Policy answers what. Consent answers why. Authorization without one of the three is a partial check that compliance treats as no check at all.
Identity resolves through Master Data Management. A single human exists as many principals across many applications, and the MDM ties them to one canonical identity. Vendor surfaces in this space include Beyond Identity, Microsoft Entra, and Ping Identity. The standard is NIST SP 800-63B, with AAL3 enrollment required for any principal that touches FinancialRecord resources.
Policy is Attribute-Based Access Control (ABAC) per NIST SP 800-162. Role assignment is the static floor; ABAC layers attribute evaluation on top (scope, clearance, time, location, resource sensitivity, environmental context). Privileged operations route through PAM (Privilege Access Management) and PIM (Privilege Identity Management) integrations. CyberArk is the most common PAM deployment; Open Policy Agent and AWS Cedar are equally first-class for policy decision points.
Consent is per-principal, per-business-reason. A user grants permission for billing-purposes contact, separately from marketing-purposes contact, separately from data-portability requests under GDPR Art. 20. Grants are revocable individually. Each grant carries a consent_grant_id that surfaces in every audit event depending on it. Reference standards: ISO/IEC 29184 (Online Privacy Notices and Consent), GDPR Art. 7 (Conditions for consent).
Master Data Management resolves the principal across every application and surface. One human exists as many principals (developer in engineering tools, customer in partner portal, reviewer in audit workflow). MDM ties them to one canonical identity.
Attribute-Based Access Control evaluates principal attributes (role, scope, clearance, time, location) against resource attributes (classification, residency, sensitivity) on every access. Static role assignment is the floor. ABAC is the ceiling.
The consent layer holds principal grants and business-reason mappings. Touching PII for marketing requires the marketing grant. Touching it for billing requires the billing grant. Grants are revocable individually, linked to consent_grant_id in every dependent audit event.
Every action passes through three independent checks. Identity resolves the principal. Policy evaluates allowance. Consent verifies the business reason. The audit event carries pointers to all three: actor.user.uid, the policy decision, and consent_grant_id. Remove any one layer and watch the specific failure mode appear.
A marketing analyst with an active session needs to send a campaign to a customer cohort. Identity resolves the analyst to a known principal with AAL2 enrollment. Policy confirms the analyst's role grants the send-marketing-email scope on the cohort attribute set. Consent is checked per recipient against the marketing_grant. Recipients without an active grant are filtered out at the gate, not at the campaign tool. The audit event for the send carries the analyst's identity, the policy decision, and the consent_grant_id (or a per-recipient null if filtered). RBAC alone would have allowed the campaign against the full cohort. Layer Zero refuses to.
The architecture lives in two places simultaneously. The interactive lets you explore the onion layer by layer, clicking into any of seven layers including Layer Zero (the gate) and Service Mesh (nested inside Application). The spec sheet renders the same model in engineering-document form, citation-stamped and signature-ready, sized to drop into an RFP response without editing.
The model itself is an extended onion. Defense-in-depth, with Service Mesh added inside the Application layer for east-west mTLS and SPIFFE workload identity per NIST SP 800-204, and Layer Zero added outside as the Identity+Policy+Consent gate per NIST SP 800-207. Application internals can use other architectures (hexagonal, clean, vertical slice). The onion describes the security control envelope, not the code organization.
The same model the interactive shows, in document form. Sized to drop into an RFP attachment without editing.
Identity + Policy + Consent gate. Runs before the onion. Every request resolves all three.
Edge filtering. WAF, DDoS, bot management, public surface inventory.
Zero-trust segmentation. East-west mTLS, per-namespace policies.
Code-layer defense. SAST, DAST, dependency hygiene, type-safe APIs.
Inside Application. East-west auth, encryption, and policy at the sidecar.
Last line. Encryption, tokenization, object-level authorization.
Execution surface. Hardened runtimes, eBPF detection, image provenance.
Identity is misrepresented. An attacker poses as a known user, service, or device to bypass authentication boundaries.
Authentication overhaul for , replaced shared-secret JWT with KMS-signed RS256; the audit ledger captured every cross-service hop.
Most teams bolting on LLM guardrails treat prompt injection as a 'validate the input' problem. It isn't. The user input IS the instruction context; there's no input-control separation to validate against. The model holds attacker-controlled text and trusted capabilities in the same context, and the prompt convinces it to combine them.
Every LLM in production is a confused deputy. When the prompt overrides the system instruction, the deputy carries out the attacker's intent with the system's authority. The mitigation isn't filtering, it's containment. Tool-permission scoping, deterministic gates, runtime audit, defense in depth.
The deterministic gate is the only honest mitigation for hallucination as a security risk. Verum's own architecture is the proof: load-bearing decisions live in code, the LLM contributes extracted facts and synthesis texture, and the production loop runs unchanged whether the model is right, wrong, or made-up. Hallucination becomes non-load-bearing texture instead of a critical-path failure.
An attacker writes a prompt that overrides system instructions, jailbreaking the model into ignoring its alignment, leaking the system prompt, or executing attacker-controlled instructions inside a privileged context.
Pre-launch threat model for a , closed seventeen prompt-injection vectors via prompt isolation and structured-output validation.
A pen-test report doesn't make you secure. A red-team engagement reveals what your detection actually catches, what your runbooks actually contain, and what your team actually does at three in the morning.
We don't write findings to a PDF and disappear. We work alongside your blue team to close, verify, and re-test until the chain is broken. The first engagement maps your kill chain end-to-end; each subsequent engagement measures the delta and quantifies operational improvement.
We engage on a rolling cadence rather than a one-shot annual assessment. Tabletops quarterly, simulated breaches semi-annually, full kill-chain walkthroughs annually. Security operations is a muscle; we exercise it.
Passive and active info gathering. The attacker's first move is to learn what's there.
First foothold. Phishing, credential abuse, known-but-unpatched CVE exploitation.
Establish presence. Persistence mechanisms survive reboots, credential rotations, and IR's first sweep.
Gain higher access. Local privilege first, then domain or cloud-tenant elevation.
Move through the environment. Service accounts, RBAC traversal, network pivots.
Extract data. The objective the previous five stages were enabling.
Stay invisible. Log tampering, timestamp manipulation, runbook reconnaissance.
Each cell names the specific controls our capabilities satisfy. Not checkmarks. Cross-referenceable against the published standards documents in under a minute.
| Capability | SOC 2 TSC | ISO 27001:2022 | GDPR | HIPAA | PCI-DSS v4.0 |
|---|---|---|---|---|---|
Secure SDLC | CC7.1, CC8.1 | A.8.25, A.8.28, A.8.30 | Art. 25, Art. 32(1)(b) | §164.308(a)(1)(ii)(B) | 6.2.1, 6.2.3, 6.3.1 |
Threat modeling | CC3.2, CC3.4 | A.5.7, A.5.8 | Art. 32(2), Art. 35 | §164.308(a)(1)(ii)(A) | 12.5.2 |
Auditing | CC6.1, CC7.1, CC7.2, CC7.3 | A.5.28, A.8.15, A.8.16 | Art. 30, Art. 32(1)(d) | §164.308(a)(1)(ii)(D), §164.312(b) | 10.2.1, 10.2.2, 10.3.1 |
Access + Data Protection | CC6.1, CC6.6, CC6.7 | A.5.10, A.5.12, A.8.3 | Art. 32(1)(b), Art. 32(2) | §164.312(a)(1), §164.312(c)(1) | 3.5.1, 7.2.1, 7.2.4 |
Network / Perimeter | CC6.6, CC6.7, CC7.1 | A.5.14, A.8.20, A.8.21 | Art. 32(1)(b) | §164.312(e)(1), §164.312(e)(2)(i) | 1.2.1, 1.3.1, 1.4.1 |
KMS + Multi-Key | CC6.1, CC6.7 | A.8.24, A.8.25 | Art. 32(1)(a) | §164.312(a)(2)(iv), §164.312(e)(2)(ii) | 3.5.1, 3.6.1, 3.7.1 |
Layer Zero (Identity + Policy + Consent) | CC6.1, CC6.2, CC6.3 | A.5.15, A.5.16, A.5.17, A.5.18 | Art. 25, Art. 5(1)(f), Art. 7 | §164.308(a)(3), §164.308(a)(4), §164.312(a) | 7.2.1, 7.2.2, 8.2.1, 8.3.1 |
AI / Agent security | CC7.1, CC7.2 | A.5.7, A.8.30 | Art. 22, Art. 35 | §164.308(a)(1)(ii)(A) | 6.3.1, 11.5.1 |
IR + Red Team | CC7.4, CC7.5 | A.5.24, A.5.25, A.5.26, A.5.27 | Art. 33, Art. 34 | §164.308(a)(6), §164.308(a)(7) | 12.10.1, 12.10.2 |
Control IDs verified at build time against the published standards. Standards versions: SOC 2 TSC 2017 (with 2022 update), ISO/IEC 27001:2022, GDPR Regulation (EU) 2016/679, HIPAA 45 CFR §164, PCI-DSS v4.0.
Engagement with Pharma, 14-day red team, 9 P1 findings, all resolved within SLA.
Hover or focus the bar to reveal · client identity protected
Substance-loaded answers paired with the specific standards, control IDs, and named vendors involved. Compliance officers can cross-reference any claim against the published documents in under a minute.
NIST SP 800-207 PEP / PDP diagram, seven-zone east-west segmentation matrix, ZTNA rollout patterns. The execution layer the Layer Zero gate runs on top of.
SD-WAN vendor matrix (Cisco, VMware, Versa, Fortinet, Palo Alto, Cato, Aruba) against Gartner SASE convergence and MEF 70.1. The perimeter report in its consulting-led form.