Last updated: October 2026
Draft notice: this page should be reviewed by a qualified professional before it is relied on.
Most CRM projects need access to the systems they’re about: your CRM, marketing platform, ecommerce store or integration tools. Those systems hold personal data about your customers and commercially sensitive information about your business. We treat that access as a responsibility, not a convenience.
These are the practices we follow on every engagement. They’re practices, not certifications. We don’t claim formal certifications we don’t hold, and if your organization needs a specific framework or questionnaire, tell us early and we’ll answer it honestly.
Access: as little as needed, for as long as needed
Least privilege. We ask for the lowest permission level that lets us do the agreed work. An audit can often be done with read-only or reporting access. Implementation work needs more, but rarely full super-admin rights across every tool. If a task needs higher permissions for a short time, we’ll ask for them for that task and suggest you reduce them afterward.
Named seats, not shared logins. We prefer a named user seat or the platform’s partner or collaborator access over a shared username and password. Named access means every change we make shows up in your audit logs under our name, and you can remove it in one step without changing anyone else’s password. If a platform only supports shared credentials, we’ll discuss how to handle that safely before we start.
Multi-factor authentication. We use MFA on every account we use to access client systems, wherever the platform supports it. If your platform enforces MFA through your own identity provider, we’ll follow your setup.
No access before agreement. We don’t request access during sales conversations or scoping calls. Access is set up only after a proposal is accepted, and only for the systems in scope.
Credentials
Where we do need to hold credentials, such as API keys or a service account, we store them in a password manager, never in email, chat messages, documents or spreadsheets. Please don’t send passwords by email. If you have to share a credential, use a one-time secret link or your own password manager’s sharing feature, and we’ll confirm once it’s stored safely.
API keys and integration tokens are created with the narrowest scopes the integration needs, labeled so you can tell what they’re for, and listed in the project handover so you know what exists.
Your data stays in your systems
We work inside your platforms wherever possible rather than copying data out. When an export is genuinely needed, for example to analyze duplicates or reconcile records against billing, we:
- export only the fields needed for that task
- store it in access-controlled storage, not on a local desktop or in email
- delete it when the task is finished, and at the latest when the project ends
We don’t use client data for any purpose other than your project. We don’t share it with other clients, and we don’t use it to build anything for ourselves.
Changes, testing and backups
Test before live. Where your platform offers a sandbox or test environment, we build and test there first. Where it doesn’t, we test with internal test records and a clearly labeled test segment, and we turn automations on in stages so problems surface on a few records instead of thousands.
Back up before changing. Before bulk updates, merges, deletions or migrations, we export the affected records and document current settings, such as workflow configuration, property definitions and integration mappings. If something needs to be reversed, there’s a known starting point.
Agree on the risky steps. Anything that can’t easily be undone, like deleting records, merging at scale, changing a lifecycle property used in reports, or sending to a large audience, is confirmed with you in writing before it happens.
Document what changed. Every engagement ends with a record of what we built, changed or removed, so your team isn’t left guessing.
When the project ends
At the end of an engagement we remove our own access where we’re able to, and ask you to confirm that our user seats, partner access and any API keys we created are revoked or transferred to your team. We delete any working exports we still hold and confirm that we’ve done so.
For ongoing CRM optimization work, we review our access with you periodically and remove anything no longer needed.
Confidentiality and agreements
We’re happy to sign your NDA or provide our own before you share sensitive details. Where we process personal data on your behalf, we can sign a data processing agreement; see data processing for how that works. Agencies working with us on a white-label basis can extend these commitments to their own clients.
If something goes wrong
If we become aware of a security incident that affects your data or your systems, such as a lost device, a compromised account or an unintended send, we’ll tell you without undue delay. We’ll explain what happened, what data or systems may be affected and what we’re doing about it, and we’ll work with you on any notification obligations you have. If we’re working under a data processing agreement, the notification terms in that agreement apply.
Questions
If your security or IT team has questions, or a questionnaire for vendors, send it through the Contact page before the project starts. We’ll answer it plainly and tell you if any of our practices don’t fit your requirements.