Security and data handling
The practices we follow when working in your Salesforce orgs and with your data: least-privilege access, sandboxes first, careful credential handling and clean offboarding.
When you bring in a consultancy, you are giving outsiders access to systems that hold customer records, consent history and commercial data. You should know exactly how that access is granted, used and removed. This page sets out the practices GeekMidst follows. Your own security policies and contract terms take precedence where they are stricter.
Our core practices
- Least-privilege access. We ask for the minimum permissions needed for the current task, ideally through a dedicated user with a permission set scoped to the work, rather than a System Administrator profile.
- Named users, never shared logins. Each GeekMidst person has their own user, so actions are traceable in your audit trail.
- Sandboxes first. Design, build and testing happen in sandboxes or development environments. Production access, when needed, is limited to deployment, verification and agreed support tasks.
- No production data on personal devices. Client data is not downloaded to personal machines or personal storage. Where a data export is needed for migration or analysis, we agree the location, retention and deletion with you first.
- Careful credential handling. Passwords, API keys and tokens are never sent by email or chat, never committed to code repositories and never hard-coded. We prefer platform features such as Named Credentials and External Credentials for integrations.
- Confidentiality. We sign NDAs on request and treat everything we see in your org as confidential.
- Deletion at the end. When an engagement ends, we ask you to deactivate our users and we delete any client data we hold, confirming this in writing.
Practices by type of data
| How we handle it | |
|---|---|
| Customer records and personal data | Accessed only in your org where possible; masked or synthetic data preferred in sandboxes |
| Test data | Uses example.com addresses and invented names; never real customers on seed lists without your approval |
| Credentials and secrets | Stored in an access-controlled password manager; rotated or revoked at offboarding |
| Code and configuration | Kept in your repository or an agreed one; no secrets in source control |
| Exports and files | Only when agreed, in an agreed location, deleted at an agreed time |
| Documentation | Shared through your chosen tools; contains no personal data beyond what is needed |
Access through the engagement lifecycle
- 01
Onboarding
We list the orgs, business units and tools we need, the permissions required and why. You create the users and approve the scope.
- 02
Multi-factor authentication
We expect MFA on every account we use and will not ask for it to be turned off. Salesforce requires MFA for direct logins; check Salesforce Help for current requirements.
- 03
During the work
Access stays scoped to the task. If we need more, we ask, explain why and let you decide.
- 04
Production changes
Deployed through your agreed release process after sandbox testing and your sign-off.
- 05
Offboarding
We provide a list of every account, connected app and credential we used so you can deactivate or rotate each one, then confirm data deletion.
What we ask of you
Good security is shared work. We will ask you to name an owner who approves access, to tell us about any policies we must follow (data residency, approved tools, change windows) and to review our users periodically. If you do not have a sandbox strategy or masked test data yet, we can help design one as part of an org health check.
For integrations specifically, our guide to securing Salesforce API integrations explains the controls we recommend. How we use AI tools in delivery is covered separately in our responsible use of AI page, and how this website handles visitor data is in the privacy policy.
Questions we hear
Do you need System Administrator access?
Will you work in our production org?
Can you work with masked or synthetic data?
Will you sign our NDA or security questionnaire?
What happens to our data when the project ends?
Review security requirements with us
If your organisation has specific security or compliance requirements for suppliers, tell us at the start so we can plan around them.
