Development Team Data Access Policy

Summary

This policy describes the process by which Vertic manages the data access for any development team member for the purposes of protecting client transactional data, this can be further expanded based on the needs and policies of specific clients.

The primary objectives of this policy are to:

Protect client data Personally Identifiable Information (PII).

Strategy Template

Detailed below is a strategy which can be further adapted based on the approved approach discussed with the client.

Vertic Admin User - a specific account setup to be used by onshore resources which has System Administrator access.
Vertic Developer User - a specific development user and license is provisioned to Vertic for developer users based offshore.
Vertic Developer Sandbox - a specific sandbox is provisioned to Vertic for development users.
Developer Profile - a specific profile is granted to the Vertic Developer User.
- Deactivate Modify All and View All on all sensitive objects which will remove access to anything that is not owned by this specific user.
- Hide PII data using Field Level Security.
- The ability to export data is removed from this user.
- This profile has login access to the dedicated sandbox.
- This user has access to release features into other environments (staging and production) via Click Deploy but does not have login access to the environment.
  - This is for the purpose of validating change sets.
- This user can be granted temporary access to other environments (staging and production) to support new releases / deployments.
  - This could be granted by a Permission Set.
- Login Hours and IP Ranges are utilised to protect access on the client side.

Considerations

Bitwarden contains access to all client environments and is maintained based on a needs basis, Vertic resources are only provisioned with access to environments that they need access to.
Copado Click Deploy has connections to all client environments (not credentials) for the purpose of deployments.
Salesforce Password Policies need to be maintained in alignment with Bitwarden to ensure access is removed (the password is changed) when a resource no longer has access to the environment in Bitwarden.
UAT Sandbox - needs to be included in the release strategy if there are multiple development environments involved.

Further Recommendations

For clients who want to take further steps to secure their environments

Copado Click Deploy - a client account is provisioned and all deployments are run through this account.

Available Configuration Options

ITEM	DESCRIPTION	NOTES

ITEM	DESCRIPTION	NOTES
Development User	A user specifically for development use to be provisioned for development activities.
Development Profile	Profiles in Salesforce define a user's access rights and permissions. Each user is assigned to a profile, and the profile determines what objects and fields the user can access. Review and customize profiles to restrict access to sensitive data. Limit the visibility and editability of certain fields and objects based on job roles.	Data Export from reports and standard export feature to be deactivated. Deactivate Modify All Data. Deactivate Modify All at object level for sensitive objects.
Sandbox Management & Deployment Process	Salesforce sandboxes are used to develop new features for release. A deployment process can be defined depending on the make up of the organisation’s sandboxes to ensure access to data is protected.	With access to a full sandbox, data needs to be protected in this environment too. Development sandboxes deploy to UAT sandbox. Approved user deploys to full sandbox for business testing. Approved user deploys approved featured from full to production.
Login Hours & IP Ranges	Specify login hours and IP ranges to control when and from where users can access Salesforce.	Recommended for environments with data to control when they can be accessed.
Field Level Security	FLS allows you to control whether fields are visible or read-only on page layouts for different profiles. Use FLS to hide sensitive fields or make them read-only for certain profiles.	Dependent on Development User and Development Profile being provisioned. Turn off access to all fields which are not required from a development perspective with particular focus on fields which contain sensitive data.
Permission Sets	Permission sets are additional permissions that can be assigned to users in addition to their profiles. This allows for more granular control over access without changing the entire profile. Create permission sets that grant additional access to specific objects or features only for users who need them.	Recommended to increase permissions of the Development Profile for fixed periods of time (eg. monthly releases).
Roles	Roles in Salesforce define a user's position in the hierarchy of the organization. They are crucial for controlling access to records through role hierarchies. Restrict access by setting up role hierarchies and defining the level of access each role has to data. Ensure that only necessary records are visible based on a user's role.
Organisation Wide Defaults	OWD settings determine the default level of access users have to records. Review and adjust OWD settings to control access at the object level. Consider using private sharing models for sensitive data and sharing rules or manual sharing for exceptions.	Lock down sensitive areas of data at the object level.
Record Types	Record types enable you to define different sets of picklist values and page layouts for different business processes. Use record types to control which users can create records of a certain type, providing more control over data access.
Apex Managed Sharing	For complex sharing scenarios, use Apex Managed Sharing to programmatically share records based on specific criteria. This allows for custom logic to be applied to determine record access.

Vertic Quality Management System (VQMS)