What we do
      Back to home
      1. Expansive FM Knowledgebase
      2. Information Security
      3. What we do

      Change Management at Expansive

      Overview of how we manage change and ensure your requirements are met through Expansive FM.

      At Expansive we understand that effective change management is critical for maintaining the reliability and security of our platform. To ensure we meet your needs and comply with industry standards, we categorize changes into Configuration Changes and Code Changes. Each type of change is handled using a robust, structured process.

      Types of Changes We Manage

      1. Configuration Changes

      Configuration changes involve modifying settings or parameters within our platform (software or infrastructure). These are typically lower-risk adjustments that do not require code modifications. Examples include:

      • Adjusting user access permissions.
      • Updating system settings or environment variables.
      • Modifying feature flags to enable or disable functionality.

      When are Configuration Changes Used?

      • When a change is required quickly and does not involve altering the underlying codebase.
      • To tailor platform behaviour to specific customer or operational needs without deploying new code.

      2. Code Changes

      Code changes involve modifications to the application’s source code or underlying infrastructure as code. These are higher-risk changes because they alter the core functionality of the platform. Examples include:

      • Bug fixes or patches.
      • Enhancing existing features or introducing new ones.
      • Updates to APIs or backend systems.

      When are Code Changes Used?

      • When the required change cannot be achieved through configuration alone.
      • To improve or expand functionality, address technical debt, or resolve security vulnerabilities.

      Example in Practice

      To give you a real-world example, let's consider how a new feature might be rolled out:

      • Configuration Change: A feature flag is toggled to enable the feature for selected customers. This allows us to deploy the feature safely without modifying the codebase.
      • Code Change: If the feature requires adjustments to the application logic or database schema, we follow our secure development process to implement and test the changes before deployment.

      Our Approach to Managing Changes

      We follow best practices and align with ISO 27001:2022 standards to ensure all changes are secure, reliable, and documented. Changes follow these steps:

      1. Request: A client asks for a change to be made. This is raised through normal support channels.
      2. Initial Assessment: Establish the type of change (config or code), evaluating the need, risk, and impact of the change.

      Configuration Change Management

      Configuration changes are subject to our Configuration Change Process, which includes:

      1. Approval: Changes are reviewed by the relevant customer success team and approved by an authorized individual.
      2. Execution: Changes are implemented in a controlled manner, with rollback plans in place.
      3. Documentation: All changes are logged in our internal customer success tools.
      4. Requester Approval: The original requester is informed of the change and asked to confirm it meets their needs and expectations
      5. Close: This change request is closed. Further adjustments are treated as new change requests.

      Our process ensures that even low-risk changes are planned and tracked to maintain platform stability.

      Code Change Management

      For code changes, we adhere to a rigorous Secure Development and Change Management Process aligned with ISO 27001:2022, which includes:

      1. Change Request Approval: All changes require sign-off from our Change Request Board (CRB) which meets fortnightly to agree changes. There are 4 outcomes from a CRB
        1. Accepted - we plan to deliver the code change within 12 months.
        2. Accepted as a priority - we plan to deliver the change in the next 3 releases
        3. Information Required - CRB needs additional information to decide
        4. Rejected - The aims of the CR are being addressed elsewhere or does not meet the strategic goals of Expansive FM and will not be done. 
      2. Requirement Definition: Clearly defining the purpose, scope, and objectives of the change.
      3. Risk Assessment: Evaluating security risks and conducting impact analysis.
      4. Secure Development: Following secure coding practices and conducting peer reviews.
      5. Testing: Comprehensive testing in staging environments, including functional, security, and regression testing.
      6. Deployment: Made under our standard process. See more details here. 
      7. Requester Approval: The original requester is informed of the change and asked to confirm it meets their needs and expectations
      8. Close: This change request is closed. Further adjustments are treated as new change requests.