What about SOC 2, ISO 27001, and vendor due diligence?

Aligned is not the same word as certified, and this is the page where the distinction has to be unambiguous. Mindfulware delivers inside environments aligned to SOC 2 Type II and ISO 27001 control expectations. The site does not claim a Mindfulware-held SOC 2 Type II report or ISO 27001 certificate, and you should not read one into the wording anywhere else on it.

The reason the alignment is meaningful anyway is where the systems run. Engagements are deployed inside your tenancy, so the audited environment in play is usually yours: your cloud account, your identity provider, your logging, your retention policy. The controls we implement — field-level encryption at rest, TLS 1.2 and above in transit, tokenization before any model call, role-based access with SSO and MFA, and full audit logging — are the ones a reviewer expects to see mapped against those frameworks.

As part of onboarding we can provide architecture diagrams, data-flow maps, pen-test summaries, and sub-processor lists. We also complete enterprise vendor security questionnaires as a matter of routine, including SIG, CAIQ, and custom brokerage due-diligence questionnaires, which is the format most of the reference clients in insurance and wealth management use.

The fastest way to start is to send the questionnaire with the engagement context attached. Every inquiry gets a reply within one business day with a clear next step, and a security package request is treated the same way as any other inquiry.

For clients under securities and insurance regulation, due diligence usually extends past infrastructure into recordkeeping. Mindfulware supports FINRA 17a-4 and SEC 17a-4 recordkeeping, NAIC Model #275 best-interest documentation, state suitability requirements, and books-and-records retention with WORM-compliant storage. Every AI-assisted output is logged with prompt, response, model version, and reviewer action so an interaction can be reconstructed on request.

Compliance is engineered in rather than bolted on, which in practice means these requirements are written into the architecture during Design and are testable when the system ships, rather than being addressed by a policy document after go-live.