Security is part of how DearestWatson designs, operates, and improves its leadership development platform. This policy summarizes our public security commitments and gives researchers, customers, and users a clear route for reporting concerns.
1. Purpose & Scope
This policy applies to the DearestWatson public website, product application, supporting cloud services, and the people and processes used to operate them. It covers the confidentiality, integrity, and availability of customer and service information.
Detailed handling of personal data is described in our Privacy Policy. Customer agreements may define additional security responsibilities or requirements.
2. Security Principles
Our security work is guided by the following principles:
- Risk-based protection — safeguards are selected according to the sensitivity of the information, credible threats, and service impact
- Least privilege — access is limited to the people and services that need it for an authorized purpose
- Defence in depth — identity, application, database, storage, deployment, and monitoring controls work together
- Data minimization — workflows receive only the information needed for their stated purpose, with bounded retention
- Secure change — product and infrastructure changes are reviewed and checked in proportion to their risk
- Evidence-based claims — we do not claim a certification, audit result, or control outcome unless it has been independently established for the stated scope
3. Data & Tenant Protection
- Production and development use separate environments and separate Supabase projects. Production services and data are configured for the Stockholm region; development uses London.
- Application access is scoped by role, company, team, assignment, and record ownership as appropriate. Database Row Level Security and server-side authorization checks protect tenant and user boundaries.
- Private recordings, transcripts, assessment responses, coaching conversations, and other restricted records are not published through the public website.
- Retention and deletion controls are defined by data category, customer configuration, legal obligations, and the rights described in the Privacy Policy.
- Secrets and privileged service credentials are kept out of browser-delivered code and are not intentionally written to application content logs.
4. Identity & Access
DearestWatson supports email and password authentication and, where configured by a customer, SAML single sign-on and Microsoft identity flows. Authorization is checked independently of the visible user interface.
- Administrative and service access must be purpose-limited and attributable.
- Access changes should follow role changes and account closure, with privileged access reviewed separately.
- Authentication sessions and callback routes are restricted to approved application and host-specific return paths.
- Customers are responsible for managing their own identity-provider settings, authorized administrators, user lifecycle, and endpoint security.
5. Platform Safeguards
- Public and application traffic is served over HTTPS, with transport and browser security headers applied at the hosting layer.
- Untrusted input, uploads, tokens, webhooks, and external callbacks are validated at their service boundaries.
- Database and storage operations use scoped policies and service-side checks rather than relying on hidden interface controls.
- Meeting capture requires an authorized workflow, participant notice or consent steps appropriate to the host, and protected upload and processing paths.
- AI requests are routed through server-controlled functions with task, model, regional, data-minimization, and output-validation boundaries.
6. Secure Development
Security and privacy are considered throughout design, implementation, testing, and release. Relevant changes are reviewed across the browser, installed application, Microsoft Teams, authentication, recording, database, storage, and external-provider boundaries.
- Source-controlled changes are subject to automated type, test, dependency, secret, configuration, and integration checks appropriate to their scope.
- Database changes use versioned migrations and preserve compatibility with installed clients that may update later than the web application.
- Security findings are assessed for exposure, exploitability, customer impact, and appropriate remediation or documented risk treatment.
- Production and development configuration must remain separated, and production personal data is not used as ordinary test data.
7. Monitoring & Incident Response
We collect security-relevant operational events needed to investigate authentication, authorization, delivery, and service failures while minimizing sensitive content in logs. Suspected incidents are assessed, contained, investigated, and recovered according to their severity and affected systems.
Where an incident affects personal data, notification decisions are made under applicable law and the relevant customer-controller arrangements. We may contact affected customers or users when action is required to protect an account or service.
8. Suppliers & Continuity
DearestWatson depends on specialist cloud and service providers. We evaluate suppliers according to the data and operational role they perform, including access, location, subprocessors, incident handling, continuity, and deletion requirements.
Continuity planning considers application hosting, identity, database and storage, AI processing, communications, and deployment dependencies. Recovery objectives and assurance depend on the relevant service, customer agreement, and verified provider configuration; this public policy does not promise a universal recovery time.
9. Shared Responsibility
Customers and users also help protect the service. Please:
- keep credentials and access links private and use your organization's approved sign-in method
- grant administrative access only to authorized people and remove it when no longer needed
- keep browsers, devices, identity-provider settings, and local security controls up to date
- use the product only for authorized purposes and avoid adding information that is unnecessary for the task
- report suspected account compromise, unintended access, or unusual activity promptly
10. Report a Vulnerability
Please report a suspected security vulnerability privately to security@dearestwatson.com. Our machine-readable contact is also published at /.well-known/security.txt.
A useful report includes the affected service or URL, a clear description, reproducible steps, potential impact, and a safe way to contact you. Please do not include secrets or unnecessary personal data in the initial report.
Act in good faith, test only against accounts and data you are authorized to use, stop if you encounter other people's information, avoid service disruption or social engineering, and give us a reasonable opportunity to investigate before public disclosure. This policy does not create a bug-bounty program or authorize access that would otherwise be unlawful.
11. Assurance & Changes
This page is a public summary, not a disclosure of sensitive configurations or a warranty of uninterrupted service. It is not a claim that DearestWatson is certified to a particular security standard. Additional evidence may be shared with customers under appropriate confidentiality and commercial arrangements when available.
We review this policy as the service, risks, suppliers, and legal requirements evolve. Material changes will be reflected in the version and update date above.