Legal
Security policy
Our commitments for how the product is built, released and supported from a security standpoint. This is a policy statement, not a certification or attestation.
Template status: draft template, not yet reviewed
1. Principles
Customer permission data stays in customer infrastructure. The product does not keep private keys or passwords in its database, and credentials never leave your server. Every historical answer states how sure it is. It follows Microsoft’s limits.
2. Secure development
Changes are code-reviewed, built from pinned dependencies, and tested automatically before release, including checks that historical answers match a known scenario. [Legal review required: describe static analysis, dependency scanning and review cadence once formalized]
3. Release integrity
Every release is signed, and the product checks each update before it installs it.
4. Third-party components
The product depends on Microsoft SDKs and a small set of open-source libraries. Known vulnerabilities in dependencies are tracked and addressed in maintenance releases. [Legal review required: SLA for dependency vulnerability response]
5. Incident communication
If we become aware of a vulnerability in the product that affects customers, we will notify affected customers through their registered contact with a description, affected versions, mitigation and the fixed version. [Legal review required: notification timelines]
6. What we do not claim
We do not currently claim any security certification or audited compliance. Ask us for the current status rather than assuming.
7. Reporting a vulnerability
See the vulnerability disclosure policy for how to report an issue and what to expect.