Cargando…
Cargando…
Compliance / Cumplimiento
Last reviewed: 2026-08-16 · Next review: 2026-11-16 (quarterly cadence)
simiriki runs on one Hetzner VPS in Ashburn, Virginia, published exclusively through Cloudflare Tunnel. PostgreSQL and Redis bind to loopback; Microsoft Entra ID remains the identity provider. This page states — without marketing — which controls exist today and what remains planned.
We do not claim certifications we don't hold. Every statement carries an explicit status marker: in-evidence, committed-on-audit, or planned. Any vendor that says "we are SOC 2" without a Type II report is making an unverified claim; we don't.
We prioritize by market: P0 covers the Mexican private sector + LATAM enterprise + US headquarters; P1 extends to cloud-security baseline and European privacy demands; P2 are regulated verticals (healthcare, banking) triggered by contract.
| Framework | Priority | Status | Description |
|---|---|---|---|
| LFPDPPP (México) | P0 | In evidence | Mexico's federal personal-data protection law. Mandatory for all Mexican customer data. Privacy notice published; ARCO rights honored within ≤ 20 business days (Art. 32). |
| SOC 2 Type II | P0 | Committed on audit | AICPA trust-services-criteria attestation. ~12-month observation period; triggered by the first enterprise contract. We do not claim a report that does not yet exist. |
| ISO/IEC 27001:2022 | P0 | Committed on audit | International information-security management standard. Controls mapped via Microsoft Compliance Manager; external Stage 1/Stage 2 audit triggered by enterprise contract. |
| NMX-I-27001-NYCE (México) | P0 | Committed on audit | Mexican national standard equivalent to ISO/IEC 27001, issued by NYCE. Relevant for Mexican government and enterprise procurement that requires the national norm. Same controls as ISO 27001; local certification triggered by contract. |
| Microsoft Cloud Security Benchmark | P1 | Planned | Microsoft's security baseline for Azure workloads. simiriki's former Azure estate was deleted on 2026-08-13; there is no current production subscription on which to claim Azure Policy enforcement. |
| CIS Microsoft Azure Foundations v2.0 | P1 | Planned | Center for Internet Security Azure-specific baseline. It does not apply to the current Hetzner runtime and would be reassessed only if a production workload returns to Azure. |
| GDPR (UE) | P1 | Planned | EU General Data Protection Regulation. Relevant if we serve European data subjects. Article 28 (subprocessor) disclosures are already published; full scope is triggered by the first customer with EU data. |
| HIPAA (EE. UU.) | P2 | Planned | US Health Insurance Portability and Accountability Act. Healthcare vertical. We do not handle US PHI today; triggered only if we enter the US healthcare market. |
| Regulación CNBV (México) | P2 | Planned | Mexican National Banking and Securities Commission rules (CUB, record retention). Mexican banking/financial vertical. Triggered by the first CNBV-regulated customer. |
P0 = highest market priority · P1 = secondary · P2 = vertical / on-contract. Status: in-evidence (controls mapped, evidence collected) · committed-on-audit (will be attested on first enterprise contract) · planned (on roadmap, not yet implemented).
Compliance is shared between Hetzner and Cloudflare (infrastructure), Microsoft (identity and integrations), simiriki, and you. The boundary is explicit. "PLANNED" flags items not yet implemented.
| Control layer | Infrastructure provider | simiriki provides | Customer provides |
|---|---|---|---|
| Physical datacenter security | Hetzner and its datacenter operators | None | None |
| Infrastructure and operating-system patching | Hetzner patches hardware, network, and hypervisor; Cloudflare operates the edge | Patches Ubuntu, Docker, PostgreSQL, Redis, and application runtimes | None |
| Application code & dependencies | None | Build, ship, patch (CycloneDX SBOM on every PR) | None |
| Identity & authentication | Provides Entra ID platform | Configures Microsoft auth; enabled users registered MFA, but CA remains report-only and emergency access is missing | Manages their Microsoft 365 admin credentials used during OAuth consent |
| Authorization & RBAC | None | Restricted SSH access, secrets outside the repository, and application-data RLS | Approves which Microsoft 365 + Azure scopes (Microsoft Graph + Azure Resource Manager) simiriki requests during connector OAuth |
| Encryption at rest | No platform-managed volume-encryption claim is made | Sensitive credentials and tokens use application-layer AES-256-GCM; offsite backups are encrypted before leaving the host when that channel is enabled | None |
| Encryption in transit | Cloudflare terminates public TLS and carries traffic over an outbound tunnel | Publishes no origin web ports; PostgreSQL and Redis bind to loopback only | Connects over HTTPS (customer-side browsers / API clients) |
| Backup & restore | Hetzner provides the primary disk; no managed PITR is claimed | Creates and verifies hourly PostgreSQL dumps, monitors their age, and maintains an encrypted offsite flow with verifiable status; restore and drill procedures are documented | Decides the retention window for their data exports |
| Logging & monitoring | Hetzner and Cloudflare provide available infrastructure/edge events | Records structured host events, runs synthetic monitors, and maintains hash-chained actor_audit_log | Reviews their own Microsoft 365 tenant's audit trail |
| Incident response | Hetzner and Cloudflare provide their platform-status notices | Detects and responds; contractual customer-notice target ≤ 24h; LFPDPPP Art. 19 governs significant-impact data-subject notice | Notifies simiriki of incidents on customer-owned Microsoft 365 surfaces |
| Data residency | Hetzner provides the current VPS in Ashburn, Virginia (US) | One host and one region; no multi-region failover | Selects vendor based on their data-residency requirements |
| Data subject rights (LFPDPPP / GDPR) | Provides platform | Honors ARCO requests within ≤ 20 business days (LFPDPPP Art. 31) | Submits ARCO requests on behalf of their employees / users |
Every third party that processes customer data on behalf of simiriki, for applicable processor/subprocessor disclosure obligations. Refreshed quarterly.
| Subprocessor | Jurisdiction | Data processed | DPA |
|---|---|---|---|
| Hetzner Cloud Hetzner Online GmbH | DE | Production compute, disk, PostgreSQL, and Redis on a single-region VPS in Ashburn, Virginia (US) | DPA → |
| Microsoft 365 + Azure / Graph + ARM Microsoft Corporation | US | Customer Microsoft 365 + Azure OAuth (read-only: 155 rules via Microsoft Graph + 46 rules via Azure Resource Manager) during scans + Graph SendMail for transactional email | DPA → |
| Stripe Stripe, Inc. | US | Payment processing. Customer email + payment-intent ID (no card data — Stripe Checkout hosts the flow). PCI DSS Level 1. | DPA → |
| Cloudflare Cloudflare, Inc. | US | Authoritative DNS, TLS termination, edge protection, and Cloudflare Tunnel; processes HTTP request metadata in transit | DPA → |
| Anthropic Anthropic, PBC | US | Claude models for diagnostics, executive memos, commercial workflows, and editorial content (executive memos run under explicit client consent: generating executive memos and quarterly analyses for clients). The site assistant and posture Audit are deterministic and do not send their inputs or findings to Anthropic. Data sent to Anthropic through its commercial API is not used to train its models (Anthropic Commercial Terms) and is retained only temporarily and in a limited way to operate the service and monitor misuse. Workflows involving personal data are processed only through Anthropic’s commercial API; they are never sent to any model provider’s free tier. | DPA → |
| Google Analytics 4 Google LLC | US | Consent-gated public-site analytics; not run in the authenticated dashboard or portal. | DPA → |
Microsoft Compliance Manager (MCM) onboarding is active. MCM is the free evidence-tracking layer bundled with our Microsoft 365 DEVELOPERPACK license; it maps Microsoft-inherited controls (typically 30–50% of the total) and tracks the remaining improvement actions against the target frameworks.
Formal SOC 2 Type II and ISO 27001:2022 audits are triggered by the first enterprise contract. We do not commit specific audit dates publicly because the assessor cost (~$40–60K USD/year) must be revenue-backed. Committed dates are available on request.
Microsoft Compliance Manager measures how much of each regulatory framework we have implemented **in our own tenant**. We instantiated the 3 assessments on 2026-05-29 as a public-transparency commitment: the score below is a snapshot, not a certification. Customer-data protection depends on the current Hetzner, Cloudflare, and simiriki controls plus the contractual DPA.
Status: baseline established 2026-05-29 · Tier 1 implementation in progress. Microsoft 365 automatic credits are already reflected; pending improvement actions are tracked in the internal compliance plan (`docs/compliance/LFPDPPP_punchlist.md`).
Last MCM export: 2026-05-29
| Assessment | Score (baseline) | Actions | Testing |
|---|---|---|---|
| AI Baseline Assessment | 0/1384 (0%) | 80 | 0 auto · 80 manual |
| Data Protection Baseline for Microsoft 365 | 173/10152 (2%) | 489 | 127 auto · 362 manual |
| Federal Consumer Protection Law - Mexico Assessment | 0/1040 (0%) | 21 | 0 auto · 21 manual |
Microsoft Graph does NOT expose the Compliance Manager score; the only sanctioned path to publish the numbers outside the Purview portal is the Excel export + re-import workflow. That is why this section refreshes per commit, not in real time.
Today: one VPS in Ashburn, Virginia (US), with no multi-region failover. If your requirement demands Mexico, the EU, or another location, it must be resolved in writing before data is sent; we do not claim coverage we do not have.
simiriki maintains a documented incident-response process. Summary of the contractual commitments:
We welcome responsible disclosure of security vulnerabilities. We acknowledge reports within 72 hours and provide safe harbor for good-faith researchers.
We will not amend this section to claim certifications we do not hold.
We hold our own product to the bar we sell. When an audit finds we overclaimed — a rule that could fake a verdict, copy that overstated autonomy — we retire the claim and record the fix here. A vendor that tells you when it was wrong is the one signal a black-box scanner cannot fake.
| Date | Area | What we found | What we fixed |
|---|---|---|---|
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — transport hardening: MTA-STS / TLS-RPT / DNSSEC / BIMI) | Restoring SPF and DMARC against the real DNS (instead of the Graph inventory that fabricated them) opened the door to measuring the rest of the email-authentication posture a generic scanner ignores: whether mail in transit is forced over TLS (MTA-STS), whether encryption failures are visible (TLS-RPT), whether the DNS zone is signed against forgery (DNSSEC), and whether the brand displays with a verified mark (BIMI). Those four hardening controls did not exist as rules. | Added four DNS-verified differentiators (LOW severity, transport/integrity hardening): EML-019 (MTA-STS — passes only with the _mta-sts announce and the HTTPS policy at "mode: enforce", RFC 8461; "testing"/"none" fail; an unreachable policy → needs_review), EML-020 (TLS-RPT — a _smtp._tls record with "v=TLSRPTv1" and "rua", RFC 8460), EML-021 (DNSSEC — a signed DS+DNSKEY delegation, RFC 4033-4035; an undetermined "null" → needs_review), and EML-022 (BIMI with a verified mark VMC over enforced DMARC — IETF BIMI draft §7.1: without enforced DMARC, BIMI is inert). Each grades the live published DNS resolved by the Azure environment's Microsoft-native resolver; any undetermined resolution falls back to needs_review, never a fabricated verdict. With this, the Email-Authentication Posture module restored 5 of the 6 placebos to real DNS-verified checks (EML-012, DKIM signing, is not observable from the published record and stays in review) and added 4 new differentiators. The set grew from 197 to 201 rules (Graph plane 151→155; ARM unchanged at 46). The per-category split — automated / conditional / needs-review — is published live at /catalogo from lib/catalog/coverage.generated.ts (the single source); this note doesn't pin a figure here that goes stale with each honesty wave. |
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — DKIM selectors restored) | After restoring SPF and DMARC against the real DNS, DKIM remained. The presence of the Microsoft 365 signing keys IS verifiable by resolving the published selector1/selector2._domainkey CNAMEs on the domain; leaving EML-002 in review when it could be graded left the third pillar of email authentication unmeasured. | Restored EML-002 (DKIM — presence of the Microsoft 365 selector1/selector2._domainkey CNAMEs, against RFC 6376 §3.6.2.1 and Microsoft Learn). It grades the live published DNS resolved by the Azure environment's Microsoft-native resolver; any undetermined resolution falls back to needs_review, never a fabricated verdict. EML-012 (DKIM signing-enabled) is NOT observable from the published DNS record and stays in review. Split after this wave: 86 rules with an automated verdict, 58 conditional, 53 needs-review, within the 197-rule set. |
| 2026-06-15 | Scan evaluators (Email-Authentication Posture — SPF + DMARC restored) | The six email-authentication rules had been moved to needs_review after we found they read a field DNS never exposes. That was honest but incomplete: SPF and DMARC ARE verifiable by resolving the actual published DNS, not the Graph inventory. Leaving them in review when they could be graded against the standard left a critical control unmeasured. | Restored EML-001/EML-011 (SPF presence and strictness, against RFC 7208 and the M3AAWG BCP — "-all" and "~all" pass; "+all"/"?all"/no-all, a duplicate record, exceeding the recursive 10-lookup limit, and the "ptr" mechanism fail) and EML-003/EML-013 (DMARC presence and full enforcement, against RFC 7489 §6.6.4 — passing only at p=quarantine/reject, pct=100, with a "rua" destination). They grade the live published DNS resolved by the Azure environment's Microsoft-native resolver; any undetermined resolution falls back to needs_review, never a fabricated verdict. Split after this wave: 86 rules with an automated verdict, 57 conditional, 54 needs-review, within the 197-rule set. EML-002/EML-012 (DKIM) follow once the selector + signing-state checks land. |
| 2026-06-15 | Scan evaluators (email-authentication DNS cluster) | Six email-authentication rules — SPF (EML-001), DKIM (EML-002), DMARC (EML-003), SPF strictness (EML-011), DKIM signing (EML-012) and DMARC reject (EML-013) — read the serviceConfigurationRecords field off the GET /domains list response, a field Graph never returns there (and which, even when fetched separately, returns the records Microsoft EXPECTS, not what is published in DNS). The result: they flagged SPF/DKIM/DMARC as missing on EVERY verified domain — a fabricated CRITICAL even on correctly-configured tenants. | All six moved to needs_review (excluded from the score, the PDF, and compliance status — never a false pass or false fail) while the real Email-Authentication Posture module is built: verification against live DNS (DNS-over-HTTPS) for SPF/DMARC and Graph dkimConfiguration for DKIM, grading policy strength (e.g. DMARC p=none = monitor-only) against CISA / NIST SP 800-177 / M3AAWG. Split after this wave: 86 rules with an automated verdict, 53 conditional, 58 needs-review, within the 197-rule set. |
| 2026-06-14 | Scan evaluators (Backup + guest-invite + email-security connector) | Three more controls described a real risk but remained in needs_review: native Microsoft 365 backup, the tenant guest-invitation posture, and the Exchange/EOP email-security family (Safe Attachments, anti-phishing, Customer Lockbox, and more). Their evaluators were waiting on a Graph endpoint or a dedicated connector — not a logic defect. | Restored OPS-003 (native Microsoft 365 backup) and TMS-002 (re-scoped to the tenant guest-invitation posture) with real evaluators — Graph app-only, no PowerShell — and added 9 Exchange/EOP email-security rules via the Graph Tenant Configuration Management connector (app-only, no PowerShell). Those 9 email-security rules are flag-gated and return needs_review until the connector is onboarded for a tenant. Split after this wave: 92 rules with an automated verdict, 53 conditional, 52 needs-review, within the 197-rule set. |
| 2026-06-14 | Scan evaluators (scope-gated restoration) | Some needs_review rules described controls that ARE readable from Microsoft Graph but required an additional read-only permission the scan did not yet request (SharePoint external sharing, federated-domain MFA, inbox-rule forwarding). These were not evaluator defects — they were a consent-scope boundary. | After granting three read-only scopes (SharePointTenantSettings.Read.All, Domain-InternalFederation.Read.All, MailboxSettings.Read) we restored 4 rules with real evaluators: DLP-012/DLP-013 (SharePoint external sharing), EXO-001 (federated-domain MFA), and EXO-004 (inbox-rule external forwarding, with its scope narrowed and the two PowerShell-only forwarding mechanisms disclosed). Each passed an independent adversarial review and keeps an honest needs_review fallback until consent is granted. Split after this wave: 92 rules with an automated verdict, 42 conditional, 63 needs-review, within the 197-rule set. |
| 2026-06-14 | Scan evaluators (restoration) | The needs_review quarantine was an honest holding state, not the end: many rules describe a real control whose evaluator was flawed. A triage of all 76 confirmed only 10 are restorable with a real evaluator from the read-only scan token — the rest depend on out-of-scope data (Exchange/Defender/Purview PowerShell, extra consent) and correctly stay in needs_review. | Restored 9 rules (DEV-003, MDM-007, MDM-011, APP-001/003/008, IAM-004, OPS-002, TMS-004) with real evaluators that read the actual tenant state, each with an honest needs_review fallback. Every evaluator passed an independent adversarial review (5 placebo defects caught and fixed before shipping). Split after this wave: 92 rules with an automated verdict, 38 conditional, 67 needs-review, within the 197-rule set. |
| 2026-06-09 | Scan evaluators (PG-8 round 2) | A full re-audit of the entire evaluator set (197 rules at the time) plus a 51-candidate adversarial verification confirmed 41 MORE evaluators whose verdict was not honestly determinable from the scanned data: 18 emitted a false CRITICAL/HIGH fail against correctly-configured tenants; 13 always passed, hiding real risk. | All 41 moved to needs_review (excluded from the score, PDF, and compliance status). Honest split updated: 92 rules with an automated verdict, 22 conditional, 83 needs-review, within the 197-rule set. Reversible: each is restored as it gets a real evaluator. |
| 2026-06-03 | Scan evaluators (PG-8) | An adversarial audit of the entire scan-evaluator set (197 rules at the time) found 41 that could fake a pass (proxy endpoints, always-present data) or fake a fail (flag a correctly-configured customer as deficient). | Retired all 41 to needs_review or fixed the logic. needs_review is excluded from the score, the PDF, and compliance status — never a fake pass, never a fake fail. |
| 2026-06-03 | Detection coverage (PG-9) | Public copy claimed every rule in the set (197 at the time) was a real evaluator. | Corrected to the honest split: ~146 rules evaluate pass/fail and ~49 need manual review, within a 197-rule set. |
| 2026-06-03 | Operación autonomy | Marketing implied the agent autonomously executes all 188 remediation playbooks. | Corrected every surface to the real split: of the 188 playbooks, the agent applies the Graph-reachable fixes autonomously via Microsoft Graph; the rest it hands to your operator as a one-click step in the dashboard, with the exact guided steps — always under your approval. simiriki never touches your tenant by hand. |
| 2026-06-02 | Power Platform rules (PG-1) | 6 Power Platform rules string-matched an unrelated Microsoft Graph feature instead of real governance data. | Retired to needs_review; built 7 real governance evaluators (live once the admin consent is granted). |
| 2026-05-28 | Status page integrity | The public status page could render a hardcoded sample "payment outage" incident when live data was unavailable. | Removed the scaffold; the fallback now reads the honest "all operational." |
This page is the public summary. The full compliance posture statement (with control-to-ISO 27001 / SOC 2 and LFPDPPP article mapping) is available on request for procurement teams.