Trust and security

mDecide handles the material your organization uses to make consequential decisions. This page summarizes the security posture, data-handling practices, access model, and responsibility split, at the level an evaluation team needs before a formal vendor assessment.

A fuller Security and Compliance Overview — populated with your instance’s region, hostname, model provider, and retention term — is delivered with each engagement and is sized for review by Legal and InfoSec. The internal artifacts behind the practices below (infrastructure definitions, audit records, incident playbooks) can be shared under NDA.

This page describes the platform as it is built and operated today. It is not a substitute for the executed services agreement, which governs warranties, liability, remedies, and notification obligations.

Compliance posture

What this is not

Being explicit about the gaps is more useful to an evaluator than a clean-looking claim.

• Not a SOC 2 Type II report. The audit is on the roadmap; the control coverage exists now, the auditor’s opinion does not.
• Not a HIPAA Business Associate Agreement. The platform does not currently process protected health information under a BAA. The technical controls are consistent with the HIPAA Security Rule; the contractual instrument is out of scope today. If your use case needs one, raise it in scoping.
• Not a compliance certification of your use of the platform. What you put into it, and who you let use it, remain yours to govern.

Mappings to a customer-named control catalog or a sector regulation can be produced on request and delivered as an appendix to your engagement’s overview document.

Data handling

What the platform stores

For your instance, the platform holds four categories of data:

Your decision content lives in your instance’s application database. The audit and configuration trails that record what the platform itself did are kept separately from the application data plane.

Encryption

Credentials are held in a managed secrets store and injected into services at start. There are no credentials in application code or container images.

Where data sits, and what leaves

• All of your data resides in the region selected for your instance. Cross-region replication is not enabled by default; if your engagement requires it, raise it in scoping.
• Outbound traffic from application services leaves through a controlled egress path, and the permitted destinations are narrow: the cloud service endpoints the platform itself depends on, and the model and embedding APIs used by the decision-support features.
• What content reaches the model API, and where that provider processes it, is documented in your engagement’s data-flow description. This is the boundary evaluators most often want drawn explicitly, and it is drawn per engagement rather than assumed.

Retention, deletion, and export

• Operational backups. The application database is snapshotted automatically on a daily cadence with a rolling retention window, and point-in-time recovery is available within that window. Restore capability is tested quarterly.
• Audit trails. The record of platform and cloud control-plane activity is retained in an immutable, service-restricted store.
• Engagement-specific retention. If your contract sets a longer or shorter retention term, it is applied to your instance and recorded in the statement of work.
• Termination. At contract end, metricsIQ runs a documented teardown that removes your instance’s application and data resources. A final snapshot is held for the period the services agreement defines and is then destroyed.
• Export. Your data can be exported in a structured format during the engagement. The mechanism and cadence are set in the statement of work.

Access control

Two layers, only one of which is yours

Your people only ever hold the second. You do not receive cloud console access to the account your instance runs in, and you do not need it — nothing in normal use requires it.

How operator access is governed

• Single sign-on only, with multi-factor authentication enforced. There are no static console users and no long-lived access keys for human operators.
• No routine root use. The cloud account root user is reserved for break-glass situations, has no access keys, and its console logins raise an alert.
• Federated deployment. Release pipelines authenticate through OpenID Connect with trust scoped to a specific source repository and branch. No static deployment credentials exist.
• Least privilege per service. Each platform service runs under a role carrying only the permissions its own function needs — read one secret, write one log stream.
• Quarterly access review. Every quarter, single sign-on assignments, roles, federated trusts, and secret-access grants are reviewed, and unused or over-broad entries are removed.

How your users’ access works

• Authentication. The sign-in mode is a deployment-time configuration: single sign-on federated with your identity provider (identity and group membership stay in your directory; no mDecide passwords exist), or local accounts managed in the instance. Where local accounts are used, passwords are hashed with Argon2 and validated against minimum length, similarity, common-password, and numeric-only rules.
• Session security. Session cookies are restricted to HTTPS and are not readable by scripts; cross-site request forgery protection applies to every state-changing request.
• Roles. The application enforces role-based permissions within your instance. The specific roles available and what each may do are configured per engagement and documented in your administrator materials.
• Account lifecycle. Your designated administrator creates, modifies, and disables your users’ accounts. That stays on your side of the responsibility line, deliberately — you know who should have access; metricsIQ does not.

What gets logged

Cloud console and API activity is recorded in an immutable audit trail. Application authentication events — logins, failed logins, password resets — are recorded as structured log events. Access to secrets is recorded at the cloud control-plane level.

Per-tenant scoping

Each engagement is provisioned as a dedicated instance with its own infrastructure. There is no shared application database, shared message broker, or shared container fleet across customers.

What that guarantees

• Content created in your instance is stored in your instance’s database and is not reachable from another instance’s services.
• A failure or compromise confined to one instance’s data plane does not, by the design of the architecture, propagate to another instance’s data plane.
• Capacity and scaling decisions are made per instance, so another customer’s workload cannot degrade yours.

What it does not guarantee

Operator access is intentionally cross-cutting. A metricsIQ operator holding the appropriate role can administer any instance in the course of routine operation, incident response, or recovery. That is what makes a managed service possible; the controls that bound it are the ones described above under operator access, and the audit trail records its use.

Third parties

The platform keeps a deliberately narrow third-party surface.

A subprocessor here means a third party that processes your application data on metricsIQ’s behalf. By default that list is two entries long: the cloud infrastructure provider, and the model API provider named in your engagement. Changes to that list — additional providers, alternate regions, exclusions — are recorded in the statement of work, and material changes are notified to your administrator on the terms the services agreement sets.

Change and vulnerability management

• Application dependency versions are pinned in lockfiles held under source control, and are scanned on a weekly cadence and on every proposed change.
• Newly published upstream versions are held in quarantine before they are allowed into those lockfiles, which limits exposure to compromised or rushed releases.
• Reported vulnerabilities are triaged on a severity basis, with critical findings taken ahead of the routine release cadence.
• Container base images are rebuilt weekly to pick up upstream patches. Operating-system patching for compute is handled by the managed container platform, and database engine patching happens in the managed maintenance window.
• Changes to the platform reach production through a reviewed, branch-protected pipeline with required automated checks.
• Incident response follows a documented severity classification with playbooks for credential exposure, unauthorized access, and account compromise. Notification obligations to you are set by the services agreement.

Shared responsibility

mDecide is a managed service. metricsIQ operates the stack; your responsibility is bounded to your organization’s use of the application.

metricsIQ operates

You are responsible for

You do not need to

Configure cloud infrastructure, arrange backups or disaster recovery, patch servers or containers, manage TLS certificates, configure network rules, administer database instances, or run the release pipeline. All of that is metricsIQ’s.

Asking for more

Evaluation teams generally want more than a summary. The supporting artifacts — data governance policy, access governance and vulnerability management policy, incident response playbooks, resilience policy, the AWS Foundational Technical Review self-assessment, benchmark reports, and the versioned architecture diagram — are available under NDA. Request them at mdecidesupport@metricsiq.ai.

Where to go next

• Architecture overview — the deployment shape these controls apply to.
• Adopting mDecide — where security review fits in the onboarding sequence.
• FAQ — shorter answers to the questions that come up most in evaluation.