Higson Security: CREST, SOC 2, Encryption & Audit (2026)

Security is where most insurance BRMS evaluations get serious

Every BRMS evaluation I run with a mid-market insurance carrier reaches the same gate: the CISO security review. The Business Analysts like the no-code authoring, the architects like the performance numbers, the CTO likes the total cost of ownership - and then the security team asks for the SOC 2 report, the penetration test results, the encryption posture, and the data-handling documentation. Vendors that cannot answer these questions cleanly get eliminated regardless of how good the product is. In my experience, security posture is not a tie-breaker; it is a gate.

Higson sits inside the regulated decision path at insurance carriers - underwriting eligibility, premium rating, claims routing, compliance triggers. Customer data passes through rule evaluation. That means Higson's security posture becomes part of the carrier's security posture, and audit findings against Higson would become findings against the carrier. We take this seriously because our customers' CISOs take it seriously. This page summarizes Higson's security certifications, controls, and regulatory alignment for the security teams evaluating us.

If you are working through a formal vendor security questionnaire, the sections below map to the most common questions. For anything not covered here - specific control documentation, the current SOC 2 report, recent penetration test attestation - your Higson contact can provide the detailed artifacts under NDA.

Higson security posture at a glance

Higson's security program covers four areas that mid-market insurance and banking security teams evaluate: independent certification and testing, data protection, decision auditability, and regulatory alignment. In my experience, these four are exactly what a CISO checklist covers, so each is addressed in detail below.

CREST-certified penetration testing

Higson undergoes periodic penetration testing by external providers certified by CREST (the Council of Registered Ethical Security Testers). CREST certification matters because it is an independent, internationally recognized accreditation for penetration testing providers - it means the testing follows rigorous methodology rather than a vendor self-assessment. Our most recent testing was performed by a CREST Certified Member in penetration testing.

What CREST certification signals

CREST accredits penetration testing companies and individual testers against demanding technical and process standards. When a carrier's CISO sees CREST-certified testing in a vendor's security posture, it signals three things: the testing was performed by accredited professionals, the methodology follows recognized standards, and the findings carry independent credibility rather than vendor marketing. For mid-market carriers whose own security teams may be lean, CREST-certified third-party testing provides assurance their internal team can rely on.

Penetration testing methodology

The penetration testing follows a structured web application security assessment designed to evaluate the scope, security, and resiliency of Higson environments. The approach simulates attacks from a malicious actor to surface vulnerabilities before they can be exploited in production. The methodology covers information gathering, active testing, vulnerability verification, and remediation notification - the standard phases of a rigorous assessment.

Remediation discipline

Penetration testing only adds value if findings are remediated and re-verified. Higson's discipline: findings from each assessment are remediated promptly, then the testing provider confirms successful remediation through re-testing. In my experience, this closed-loop process - test, remediate, re-verify - is what separates security testing as a checkbox from security testing as a genuine control, and I recommend carriers ask every BRMS vendor whether their pen-test findings are independently re-verified after remediation. Some findings relate to customer deployment configuration rather than the Higson product itself; for those, we maintain deployment best-practice guidance and tutorials so carrier teams can configure secure environments.

SOC 2 Type II

SOC 2 Type II is the attestation insurance and banking security teams most commonly require from software vendors. Unlike SOC 2 Type I (which evaluates control design at a point in time), Type II evaluates whether controls operated effectively over a period - typically 6-12 months. This is the stronger attestation because it demonstrates sustained control operation rather than a snapshot.

Higson's SOC 2 Type II covers the trust service criteria most relevant to insurance carriers: security (protection against unauthorized access), availability (system uptime and operational resilience), and confidentiality (protection of sensitive data passing through rule evaluation). The SOC 2 report itself is available to prospects and customers under NDA as part of the vendor security review process.

For security teams: the SOC 2 report is the single most useful artifact for your vendor review. It documents the control environment, the auditor's testing, and any exceptions. Request it early in your evaluation - your Higson contact can provide it under NDA so your team can complete the security assessment in parallel with the technical PoC.

Encryption and data protection

Higson protects data through encryption in transit and at rest. Data moving between the carrier's systems and Higson is encrypted using TLS; data stored by Higson is encrypted at rest. For carriers with specific data-residency requirements, Higson's deployment flexibility means the carrier controls where data lives.

Data residency through deployment choice

Higson runs on AWS, Azure, GCP, Kubernetes, or on-premise. This matters for data protection because the carrier chooses the deployment that meets their data-residency and sovereignty requirements. A carrier required to keep data in a specific jurisdiction deploys Higson in that jurisdiction's cloud region or on-premise. Higson does not force data through a vendor-controlled multi-tenant environment - the carrier controls the data boundary.

Minimal data exposure by design

Higson evaluates rules against the data the carrier sends in each decision request, and returns the decision. The architecture does not require Higson to store the carrier's policy or claims data permanently - rule evaluation is request-response. This minimizes the data Higson holds, which in turn minimizes the carrier's exposure. Audit logging captures decision records (rule version, inputs, output) per the carrier's retention configuration, but the architecture does not require Higson to become a permanent store of sensitive customer data.

Audit trail and decision traceability

Audit trail is both a security control and a regulatory requirement. Every rule change in Higson is logged - who changed what rule, when, and with what business reason. Every decision execution is logged - which rule version fired, what inputs, what output, what timestamp. This serves two audiences: security teams who need to know who modified decision logic, and regulators who need to know why a specific decision was made.

Why audit trail matters for insurance security

In a regulated decision path, the question "who changed this rule and why" is a security question (unauthorized rule modification is a threat) and a compliance question (state DOI examinations ask for decision rationale). Higson's audit trail answers both. A rule change shows the author, timestamp, version, and business reason - not just a developer commit hash. A decision execution shows the rule version that fired and the inputs that produced the output. For NAIC Model Bulletin on AI Use in Insurance compliance, this decision-level audit trail is the artifact regulators expect.

Version control and rollback

Rule changes flow through version control with rollback capability. If a rule change produces unintended behavior, the carrier can roll back to the prior version - the audit trail records both the change and the rollback. This is a security control (limiting blast radius of a bad rule change) and an operational control (recovering from errors quickly). For the broader discipline around rule change governance, see our rules engine deployment guide.

Regulatory and framework alignment

Higson's security program aligns with the regulatory frameworks insurance and banking carriers operate under. Alignment is not the same as certification against every framework, but it means Higson's controls map to the requirements carriers face.

NAIC Insurance Data Security Model Law

The NAIC Insurance Data Security Model Law establishes data-security requirements for insurance licensees, adopted by a growing number of states. Higson's controls - encryption, access control, audit trail, incident response, third-party penetration testing - map to the model law's requirements. Carriers subject to state versions of the model law can incorporate Higson's posture into their own compliance documentation.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover) is the de-facto standard many carriers use to structure their security program. Higson's controls map to the Protect function (access control, encryption, audit) and support carriers' Detect and Respond functions through audit logging. Carriers using NIST CSF to structure vendor assessments can map Higson's posture to the framework's categories.

GDPR for EU deployments

For carriers operating in the EU or processing EU resident data, Higson's deployment flexibility and data-minimization architecture support GDPR compliance. Data residency through deployment choice, encryption, and minimal data retention align with GDPR's data-protection principles. Decerto, Higson's maker, operates from the EU and is subject to GDPR directly.

NAIC Model Bulletin on AI Use in Insurance

For carriers using Higson's ONNX runtime to combine ML models with rules, the audit trail supports NAIC Model Bulletin on AI Use in Insurance compliance - decision-level explainability and audit records for AI-influenced decisions. The hybrid pattern (rules wrapping ML inference with single audit trail) is covered in detail in our ML governance article.

For security teams: what to request during evaluation

I recommend security teams request these artifacts early in a Higson evaluation so the security review runs in parallel with the technical PoC rather than blocking it at the end.

1. SOC 2 Type II report (under NDA) - the single most useful artifact for your vendor security assessment

2. Most recent penetration test attestation - CREST-certified, with remediation confirmation

3. Encryption documentation - in-transit and at-rest specifics for your deployment model

4. Data flow documentation - what data Higson processes, what it retains, where it lives in your chosen deployment

5. Audit trail specification - what is logged, retention configuration, export capability for your SIEM

6. Deployment security guidance - configuration best practices for your AWS / Azure / GCP / on-premise deployment

Your Higson contact can provide these under NDA. In my experience, carriers that request the security artifacts during the first two weeks of evaluation complete their security review without it becoming the bottleneck that delays the decision. Carriers that defer security review to the end frequently discover the SOC 2 request alone adds 2-4 weeks they did not budget for.

FAQ

Is Higson CREST certified?

Higson undergoes periodic penetration testing by CREST-certified providers - the most recent testing was performed by a CREST Certified Member in penetration testing. CREST (Council of Registered Ethical Security Testers) is an internationally recognized accreditation for penetration testing providers, meaning the testing follows rigorous methodology and the findings carry independent credibility. CREST-certified third-party testing provides assurance that mid-market carriers' own security teams can rely on, particularly when their internal security team is lean.

Does Higson have SOC 2 Type II?

Higson maintains SOC 2 Type II attestation covering the security, availability, and confidentiality trust service criteria most relevant to insurance carriers. SOC 2 Type II is stronger than Type I because it evaluates whether controls operated effectively over a period (typically 6-12 months) rather than at a single point in time. The SOC 2 report is available to prospects and customers under NDA as part of the vendor security review process. (Verify current attestation status with your Higson contact.)

How does Higson encrypt data?

Higson encrypts data in transit using TLS and data at rest. For data residency, Higson's deployment flexibility (AWS, Azure, GCP, Kubernetes, on-premise) means the carrier controls where data lives - a carrier required to keep data in a specific jurisdiction deploys Higson in that region or on-premise. Higson's request-response architecture also minimizes data exposure: rule evaluation does not require Higson to permanently store the carrier's policy or claims data.

What audit trail does Higson provide?

Higson logs every rule change (who changed what rule, when, with what business reason) and every decision execution (which rule version fired, what inputs, what output, what timestamp). This serves security teams (detecting unauthorized rule modification) and regulators (NAIC Model Bulletin decision-level audit trail). Rule changes flow through version control with rollback capability. The audit trail shows the author and business reason rather than just a developer commit hash, which is what state DOI examinations require.

Is Higson compliant with NAIC and NIST frameworks?

Higson's security controls align with the NAIC Insurance Data Security Model Law (encryption, access control, audit trail, third-party penetration testing) and map to the NIST Cybersecurity Framework's Protect, Detect, and Respond functions. For carriers using Higson's ONNX runtime for ML integration, the audit trail supports NAIC Model Bulletin on AI Use in Insurance compliance. Alignment means Higson's controls map to carrier requirements; carriers incorporate Higson's posture into their own compliance documentation.

What security artifacts should I request when evaluating Higson?

Request these early so security review runs parallel to the technical PoC: (1) SOC 2 Type II report under NDA - the most useful single artifact; (2) most recent CREST-certified penetration test attestation with remediation confirmation; (3) encryption documentation for your deployment model; (4) data flow documentation - what Higson processes, retains, and where; (5) audit trail specification including SIEM export; (6) deployment security guidance for your cloud or on-premise environment. Requesting these in the first two weeks prevents security review from becoming the decision bottleneck.

Related reading

• How to Choose a Rules Engine: 9-Criteria Buying Checklist - security is Criterion 7 of the evaluation framework.

• Higson Rules Engine Deployment Guide - secure deployment configuration and rule-change governance.

• What is a Rules Engine? Complete Guide for Insurance 2026 - the BRMS primer. PILLAR MAIN.

• Machine Learning Problems: ML Governance & BRMS Guardrail - audit trail for AI-influenced decisions and NAIC compliance.

• Decoupling Decisions: BRMS in Microservices Architecture - security boundaries in distributed deployment.

• Simplifying Insurance Claims Management - secure claims data handling.

• Higson Business Rules Management System - product overview.

Talk to Higson

Security is a gate in BRMS evaluation, and Higson is built to clear it cleanly for mid-market insurance carriers and banks. CREST-certified penetration testing, SOC 2 Type II attestation, encryption in transit and at rest, decision-level audit trail, and alignment with NAIC and NIST frameworks - the posture your security team needs to complete their review without Higson becoming the bottleneck.

Higson is built for mid-market insurance carriers $500M-$5B GWP and mid-market banks $1B-$20B AUM. We have 200+ insurance implementations via Decerto since 2005 including Allianz, BNP Paribas Cardif, InterRisk, Warta, and Nationale Nederlanden - carriers whose security teams have completed exactly the review your team is about to run. Higson Runtime executes at 0.23 ms P50 latency and 9 000 req/s sustained, and the security controls described above operate at that scale.

If your security team is ready to begin a vendor review, your Higson contact can provide the SOC 2 report, penetration test attestation, and supporting documentation under NDA so the security assessment runs in parallel with your technical evaluation.

Three ways to start:

• Try Higson on AWS Marketplace at $0.63 / hour - deploy in your own AWS account within your own security boundary.

• Schedule a security-focused walkthrough - we will walk your security team through controls, audit trail, and deployment options.

Citations

1. NAIC Insurance Data Security Model Law (#668) - state data-security requirements for insurance licensees. https://content.naic.org/

2. NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (December 2023, updated 2024-2025) - audit-trail requirements for AI-influenced decisions. https://content.naic.org/sites/default/files/inline-files/2023-12-4 Model Bulletin_Adopted_0.pdf

3. NIST Cybersecurity Framework - the de-facto standard for structuring security programs. https://www.nist.gov/cyberframework

4. NIST SP 800-53 - security and privacy controls reference. https://csrc.nist.gov/

5. CREST (Council of Registered Ethical Security Testers) - penetration testing accreditation standard. https://www.crest-approved.org/

6. AICPA SOC 2 Trust Services Criteria - the framework underlying SOC 2 attestation. https://www.aicpa.org/

7. GDPR (General Data Protection Regulation) - EU data protection framework. https://gdpr.eu/