/
Configuration Management

Configuration Management

Owned by Jan Tenenberg
06 May 2025

1. Purpose

This policy defines the controls and procedures required to manage the configuration of the Salesforce environment in a secure, consistent, and controlled manner. It ensures that configuration changes do not compromise the confidentiality, integrity, or availability of information processed through Salesforce.

2. Scope

This policy applies to:

  • All Salesforce production and sandbox environments

  • All employees, contractors, and administrators involved in Salesforce administration and development

  • All configuration elements, including metadata, security settings, custom objects, automation, and integrations

3. Policy Statements

3.1. Configuration Baseline

  • A secure baseline configuration must be defined, documented, and approved for all Salesforce environments.

  • Baselines must reflect industry best practices (e.g., OWASP, CIS Salesforce benchmarks) and Salesforce security guidelines.

  • Deviations from the baseline must be formally documented, risk-assessed, and approved.

3.2. Change Management

  • All configuration changes must follow a formal Change Control Process, including:

    • Risk and impact assessment

    • Approval by designated roles (e.g., Salesforce Admin, IT Security)

    • Testing in a sandbox environment before deployment

    • Rollback plans

3.3. Version Control and Documentation

  • Configuration items (metadata, Apex code, Flows, etc.) must be stored in version-controlled repositories (e.g., Git) using CI/CD tools (e.g., Copado, Gearset, Bitbucket Pipelines).

  • All deployments must be traceable with details including:

    • Change description

    • Date and time

    • Responsible individual

    • Test and approval status

3.4. Configuration Review and Monitoring

  • A monthly configuration review must be conducted to verify:

    • Unauthorized changes

    • Compliance with baseline configuration

    • Deactivated or obsolete components

  • Automated tools (e.g., Salesforce Shield, Security Center, or third-party scanners) should be used to monitor changes and misconfigurations.

3.5. Segregation of Duties

  • Salesforce configuration and deployment responsibilities must be segregated:

    • Developers/designers should not deploy directly to production.

    • Code and metadata must be peer-reviewed and approved before release.

    • Only authorized personnel may perform administrative functions.

3.6. Security Configuration Controls

  • The following configuration areas must be secured and reviewed quarterly:

    • Profiles, Permission Sets, Role Hierarchy

    • Sharing Rules and Field-Level Security

    • Login IP Ranges, Login Hours

    • OAuth Connected Apps and API Access

    • Audit Trail, Field History Tracking

3.7. Backup and Recovery

  • Configuration backups must be taken before major changes and stored securely.

  • The organization must be able to restore critical metadata and configuration using tools like Salesforce DX, Metadata API, or third-party backup platforms.