Compliance & Regulatory Posture

What this document is (and what it isn’t)

If you need SOC 2 Type II attestation for Lictor as a vendor: that’s planned for Q2 2027. Until then, vendor risk should be assessed against the public source code, this document, and our public Trust Center page (when published).

SOC 2 Trust Services Criteria

Lictor’s products contribute evidence to the following SOC 2 TSC Common Criteria categories. The mapping below is what to put in your control matrix.

CC6: Logical and Physical Access Controls

CC7: System Operations

CC8: Change Management

The Lictor source code is open (Apache 2.0 for OSS components; source-available for Guardian). Every change is tracked in Git with cryptographic signatures from CI. Customers self-verifying our change controls should reference our public commit history at github.com/Raffa-jarrl/Lictor-AI.

CC9: Risk Mitigation

Patrol and Guardian are defensive, observe-only controls. They do not create new attack surface (Patrol only reads what is already public, single-lane and credential-less; Guardian is an isolated per-tenant SaaS). The redact-at-source invariant ensures Lictor never accumulates the live secrets it would need to be a high-value target itself.

GDPR: Article 32 (Security of processing)

Article 32 requires data controllers and processors to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” Lictor’s products map onto specific Article 32(1) measures:

32(1)(a): Pseudonymisation and encryption

• Patrol never stores or transmits a live secret. Every finding carries only a redacted 16-character fingerprint, never the credential itself. This is pseudonymisation by construction.
• All Patrol↔Guardian transit is HTTPS (TLS 1.2+).
• Magic-link auth tokens are stored as SHA-256 hashes in the database; raw tokens never persist server-side.

32(1)(b): Confidentiality, integrity, availability, resilience

• Confidentiality: bearer-token authentication on every ingest call; no cross-account read paths in Guardian’s query layer.
• Integrity: append-only audit log enforced via Postgres trigger. UPDATE that modifies audit content + DELETE on audit_log raise a SQL exception.
• Availability: Guardian is a stateless web layer over Postgres; failover is a database-level concern.
• Resilience: documented incident-response runbook (Phase 4 deliverable; tracked in LAUNCH_PLAN.md).

32(1)(c): Restoration of availability

Guardian’s data model is fully reconstructable from Postgres dumps. Patrol’s findings are append-only and idempotent (stable identifiers, so retries don’t double-count).

32(1)(d): Regular testing

• Lictor’s test suite covers the privacy invariants. The fingerprint round-trip is verified in CI. The wire-format schema is enforced in code via Zod.
• Public CI runs the full test suite on every commit. Test failures block merges.

32(2): Risks of accidental loss, alteration, disclosure

The wire-format privacy invariants make accidental disclosure of user content categorically impossible. The data Lictor collects cannot be reversed into the data it represents. This is design-level mitigation, not policy-level.

Data subject rights (Articles 15 to 22)

Right to erasure is implemented via cascading foreign keys: deleting an account row removes every related row (incidents, sessions, magic_links). The audit log persists with account_id nullified, which SOC 2 CC7.5 requires (incident communication evidence) but with PII anonymized. One DELETE satisfies Article 17 for a Lictor account.

EU AI Act: the relevant articles

The EU AI Act is in phased enforcement through 2026 and 2027. Lictor’s products are most relevant to providers and deployers of high-risk AI systems (Annex III categories) and to general-purpose AI providers.

Article 9: Risk management system

Article 9 requires high-risk AI providers to “establish, implement, document and maintain a risk management system.” Lictor’s role:

• 9(2)(a) Identification of risks. Lictor’s 48-check audit catalog provides a starting taxonomy of AI-app risk classes (leaked secrets, exposed data, insecure AI-agent surfaces, misconfiguration). Patrol tracks observed instances on your public surface and Guardian aggregates them per deployment.
• 9(2)(b) Estimation and evaluation. Patrol findings carry severity (critical/high/medium/low/info); Guardian aggregates by severity for trend analysis.
• 9(2)(c) Post-market monitoring. Guardian is a post-market monitoring system. Audit log export satisfies the documentation requirement.
• 9(2)(d) Risk-management measures. The audit’s fix-it remediation, run before you ship, and Patrol’s redact-at-source detection are technical risk-management measures.

Article 12: Record-keeping

Article 12 requires automatic logging of events relevant to the operation of high-risk AI systems. Guardian’s incident store + audit_log together provide a technical record of the system’s risk-relevant events. Retention is configurable per account.

Article 14: Human oversight

Lictor’s audit and Patrol monitoring provide automated detection, but the human-oversight requirement is a property of the deploying organization. Lictor enables Article 14, but it does not satisfy it.

Article 26: Obligations of deployers

Deployers must “monitor the operation of the high-risk AI system.” Guardian provides the monitoring substrate; the Slack webhook + audit log + per-incident drill-down provide the practical monitoring tools.

Article 50: Transparency obligations

For deployers using AI to interact with humans, Article 50 requires that humans be “informed that they are interacting with an AI system.” Lictor’s audit flags AI-agent surfaces in your codebase so you can add the required disclosure, but informing your end-users that they are interacting with an AI system remains the deployer’s responsibility.

How Lictor aligns with the NIST AI RMF

The NIST AI Risk Management Framework maps cleanly onto Lictor’s product surfaces:

ISO/IEC 42001 (AI Management Systems)

ISO/IEC 42001 (published 2023) is the first AI-specific management-system standard. Lictor contributes evidence to the following clauses:

• 8.2 (Operational planning and control): the pre-ship audit + Patrol monitoring
• 8.3 (Risk treatment): the audit’s fix-it remediation + Patrol redact-at-source
• 9.1 (Monitoring, measurement, analysis): Guardian’s dashboard
• 9.2 (Internal audit): Guardian’s audit log export

ISO/IEC 42001 certification for the Lictor company itself is a Q3 2027 target, contingent on revenue.

What Lictor itself does for compliance

We’re a security company. Walking the talk:

• Open source where it doesn’t conflict with the business model. Apache 2.0 on the skill suite: the 48-check audit plus explain, fix-it, and rotate, every check a readable markdown file. The patent grant in Apache 2.0 is what enterprise legal teams want to see.
• Hosted where the product IS the operations. The monitoring platform (Patrol + Guardian) runs as a paid hosted service, not a public download.
• Privacy-by-design wire format. No live secret ever crosses the Patrol→Guardian boundary; the architecture prevents data accumulation that would itself become a high-value target.
• CI enforced on every commit. cargo fmt --check, clippy with -D warnings, full test suite, both native and WASM targets.
• Append-only audit logs. Database triggers prevent tampering with audit content, even by a privileged operator. The only allowed UPDATE is FK-driven account_id = NULL (for GDPR Article 17).
• Coordinated disclosure policy. See SECURITY.md.

Trust Center (planned, Q1 2027)

Once Guardian has paying customers, the public Trust Center at lictor-ai.com/trust will publish:

• Real-time uptime / SLA metrics
• Vendor list (sub-processors)
• SOC 2 Type II attestation report (under NDA)
• Pen-test results (under NDA)
• Security questionnaire (CAIQ) pre-filled

If you need any of the above for vendor risk review and Lictor doesn’t yet have them: tell us. We prioritize Trust Center maturity by which deal it unblocks.

Questions / contact