Cargando…
Cargando…
Compliance / Cumplimiento
Last reviewed: 2026-05-27 · Next review: 2026-08-27 (quarterly cadence)
simiriki runs on Microsoft Azure and Microsoft 365, with identity in Microsoft Entra ID and data in single-region Azure PostgreSQL (East US 2). This page states — without marketing — which regulatory frameworks we target, which controls exist today with evidence, and what is committed or 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 | In evidence | Microsoft's unified security baseline mapped to all major frameworks. Azure Policy initiative deployed at subscription scope; Defender for Cloud enables the regulatory-compliance dashboard. |
| CIS Microsoft Azure Foundations v2.0 | P1 | In evidence | Center for Internet Security Azure-specific baseline. Enforced via Azure Policy on rg-simiriki-prod-eastus2 and monitored in the Defender for Cloud Secure Score. |
| 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 Microsoft Azure (cloud provider), simiriki (SaaS provider), and you (the customer). The boundary is explicit. "PLANNED" flags items not yet implemented.
| Control layer | Microsoft Azure provides | simiriki provides | Customer provides |
|---|---|---|---|
| Physical datacenter security | Yes (all) | None | None |
| OS patching of platform services | Yes (Container Apps, PG Flex, Redis, Front Door — managed) | None | None |
| Application code & dependencies | None | Build, ship, patch (CycloneDX SBOM on every PR) | None |
| Identity & authentication | Provides Entra ID platform | Configures customer auth (Entra External ID — PLANNED); MFA enforced on all admin | Manages their M365 admin credentials used during OAuth consent |
| Authorization & RBAC | None | Least-privilege RBAC on Azure; RLS on application data | Approves which Microsoft 365 + Azure scopes (Microsoft Graph + Azure Resource Manager) simiriki requests during connector OAuth |
| Encryption at rest | Provides platform-managed keys (PMK) by default | Encrypts data at rest; PLANNED: Customer-Managed Keys (CMK) | None |
| Encryption in transit | Provides TLS endpoints | Enforces TLS 1.2 minimum end-to-end | Connects over HTTPS (customer-side browsers / API clients) |
| Backup & restore | Provides Azure PG PITR + GRS blob storage | Configures backups; runs restore drills (PLANNED first drill 2026-07-15) | Decides the retention window for their data exports |
| Logging & monitoring | Provides Log Analytics + Application Insights infrastructure | Configures collection; instruments events; runs hash-chained actor_audit_log | Reviews their own M365 tenant's audit trail |
| Incident response | Provides Azure Service Health alerts | Detects, responds, notifies customers within ≤ 24h (LFPDPPP Art. 20) | Notifies simiriki of incidents on customer-owned M365 surfaces |
| Data residency | Provides regional infrastructure | Single-region East US 2 today (PLANNED per-customer multi-region under R4) | Selects vendor based on their data-residency requirements |
| Data subject rights (LFPDPPP / GDPR) | Provides platform | Honors ARCO requests within ≤ 20 business days (LFPDPPP Art. 32) | Submits ARCO requests on behalf of their employees / users |
Every third party that processes customer data on behalf of simiriki, per LFPDPPP Article 28 / GDPR Article 28. Refreshed quarterly.
| Subprocessor | Jurisdiction | Data processed | DPA |
|---|---|---|---|
| Microsoft Azure Microsoft Corporation | US | Compute, storage, database, identity, email — all customer data (East US 2 region) | 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 → |
| Amazon Web Services (S3) Amazon Web Services, Inc. | US | Database backup destination (legacy). Daily PG logical dumps, encrypted at rest (us-east-2). Under migration to Azure GRS. | DPA → |
| Cloudflare Cloudflare, Inc. | US | Authoritative DNS resolution for simiriki.com — DNS records only, no customer data | DPA → |
| Anthropic Anthropic, PBC | US | AI processor (Claude commercial API) for finding generation, recommendations, and copy. Receives scan configuration + finding metadata — never credentials or tokens. Not used to train its models (Anthropic Commercial Terms); temporary, limited retention. | DPA → |
Microsoft Compliance Manager (MCM) onboarding is active. MCM is the free evidence-tracking layer bundled with our M365 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 our starting point, not our average. Customer data protection does NOT depend on our internal score — it depends on Microsoft Azure controls + the contractual guarantees in our DPA, both live in production.
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: single-region Azure East US 2. Per-customer multi-region deployment is under R4 design (post product-market fit). If your residency requirement demands a specific region (e.g. Mexico Central or the EU), let us discuss it before signing — we will 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 M365 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 M365 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 189 remediation playbooks. | Corrected every surface to the real split: of the 189 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.