Security is a priority we brought with us.

1. A security-conscious mindset, not security marketing

Security has been central to the founder's professional environment from the start. Working in cybersecurity means seeing how much trust companies place in systems that hold sensitive information, how costly weak controls can be, and why security needs to be considered early instead of bolted on later. Ten CRM is being built with that awareness.

What that means in practice: reduce trust, minimize access, isolate tenants, protect credentials, log sensitive actions, test the controls, and do not make security claims that are broader than the implementation.

We will not use phrases such as “military-grade” as a substitute for explaining the controls that matter. We also will not claim certifications, audits, or security testing that have not actually been completed.

2. Production launch security baseline

Before accepting paid customer CRM data at broad availability, Ten CRM intends to require the following controls or documented equivalents:

• workspace or organization identifiers applied consistently to tenant-owned records;
• backend and database authorization that enforces tenant boundaries;
• managed authentication, secure password handling, session expiration, and account-recovery controls;
• multi-factor authentication for privileged Ten CRM administrative access and support for strong customer authentication where the production identity provider allows it;
• role-based permissions and least-privilege defaults;
• server-side secrets management with no long-lived provider credentials shipped to the browser;
• encrypted network transport for production traffic;
• audit-relevant logging for sensitive account, permission, and administrative actions;
• rate limiting and abuse controls appropriate to exposed endpoints;
• backup and recovery procedures with documented restoration expectations;
• dependency, patch, and deployment-management practices appropriate to the production stack; and
• private, tenant-scoped authorization for stored documents and attachment metadata;
• short-lived or authorization-checked access paths for document previews and downloads;
• documented data export, retention, and deletion procedures.

3. Customer data isolation

One customer's CRM data should not become another customer's data because of a missing filter in a frontend request. Tenant separation is intended to be enforced at the backend and database layer, with organization-scoped authorization applied consistently to contacts, companies, deals, activities, tasks, templates, integrations, and administrative records.

Development and testing should use synthetic, fictional, or intentionally provisioned test data wherever practical. Customer production data is not intended to become a convenient test fixture.

4. Identity, permissions, and administrative access

Ten CRM intends to separate ordinary workspace access from privileged administrative operations. Production access should be limited to personnel who need it for operation, security, or support; shared administrative credentials are not part of the intended design.

Connected integrations will be designed around provider-supported authorization such as OAuth and scoped API credentials. We will request the narrowest practical permissions for the feature. For example, sending an email should not automatically require reading an entire mailbox.

5. Documents and connected attachments

Documents can contain some of a customer's most sensitive business information, so the planned design treats them as protected tenant data rather than public assets. Ten-hosted files should be private, associated with the workspace that owns them, and made available only after authorization checks. File identifiers or copied URLs should not be sufficient to cross a tenant boundary.

For attachments that remain with a connected email or cloud provider, Ten CRM's design goal is to retain only the metadata needed to associate and surface the file, then retrieve or render it when an authorized user requests a preview. Saving a permanent copy into Ten Documents is an explicit action. Provider credentials remain protected server-side and should be scoped to the minimum permissions required for the enabled feature.

6. Logging, monitoring, recovery, and incident handling

A secure design still needs secure operations. The launch plan includes audit-relevant logging, monitoring of meaningful security and availability events, controlled production changes, backup and recovery procedures, and a documented path for investigating suspected incidents.

If a security incident materially affects customer data, Ten CRM intends to assess scope, contain the issue, preserve relevant evidence, remediate the cause, and provide notices required by applicable law and contractual commitments.

6. Security testing and vulnerability management

Ten CRM will use security review and testing that is proportionate to the product's maturity and risk. The goal is to identify meaningful weaknesses, fix material findings, and verify important controls before expanding access.

Security-sensitive changes should receive more scrutiny than cosmetic changes. Authentication, tenant isolation, integration permissions, secrets handling, and data-access paths are examples of areas that deserve targeted review and testing.

Independent penetration testing may be added as the product, customer base, contractual requirements, or risk profile justify it. We would rather scale security validation deliberately than advertise a specific assessment before it has been commissioned.

A penetration test, audit, certification, or other independent assessment will be described as completed only after it has actually been completed.

8. Infrastructure and service providers

Ten CRM will rely on reputable infrastructure and software providers where doing so improves reliability and security, but provider names are not the security strategy by themselves. Our responsibility is to configure those services appropriately, limit the data and permissions involved, protect credentials, and understand the trust placed in each dependency.

Service-provider categories and material data-handling relationships are described in the Privacy Policy. As the production architecture is finalized, customer-facing documentation will be updated to reflect material subprocessors and security commitments.

9. Vulnerability reporting

If you believe you found a vulnerability or security issue affecting Ten CRM, contact support@tencrm.app with enough detail for us to reproduce and investigate it. Please avoid accessing data that does not belong to you, disrupting service availability, using social engineering against Ten CRM personnel, or publicly disclosing an issue before we have a reasonable opportunity to investigate and address it.