Security & Salesforce Access

Careful access. Clear customer control.

Ostrelis treats access to a customer's Salesforce environment as something to grant deliberately, use only where needed and remove when it is no longer required.

Working approachProportionate to each engagement

Named accounts and authentication

Ostrelis uses individual named Salesforce accounts for people working in a customer environment. Shared passwords are not requested or used. Accounts should be protected by multi-factor authentication and, where the customer uses single sign-on, follow the customer's identity and access policies.

Credentials must not be sent through website enquiry forms. Account setup and any required secrets are handled through an agreed secure route appropriate to the engagement.

Least-privilege access

Access should be limited to the permissions, environments and period needed for the agreed work. A broad administrator profile is not treated as the default when a narrower permission set can support the task.

Customers remain in control of their Salesforce access. They create or approve accounts, can review the permissions provided and can suspend or remove access at any time. Ostrelis asks for unnecessary access to be removed when work ends or responsibilities change.

Sandboxes and testing

Where the work and available environments allow, changes are developed or tested in a sandbox before production. Testing is proportionate to the change and may include agreed acceptance checks, regression checks for affected processes and confirmation of deployment or rollback steps.

Some urgent support tasks or production-only investigations may need a different approach. In those cases, the intended action, risk and validation steps should be agreed before making a change wherever circumstances allow.

Change management and documentation

Salesforce work is prioritised and delivered through the change process agreed with the customer. Material changes should have a clear purpose, identified owner, appropriate testing and a record of what was changed.

Documentation is kept proportionate to the work and may include requirements, configuration notes, test evidence, deployment information and customer-facing handover. This supports review, continuity and future maintenance.

Handling customer data

Ostrelis accesses customer data only where it is needed for the agreed service or investigation. Data should not be copied into unmanaged tools or retained outside the customer environment without a documented need and appropriate approval.

Engagement-specific security, confidentiality, retention and incident requirements are agreed with the customer. This page describes Ostrelis's normal working approach and does not replace those written arrangements.

Discuss your access requirements ↗