Managing Incidents and Changes

How to complete your incident and change controls.

OVERVIEW

Incidents:

Effective incident management is crucial in ensuring that your customers and system users are protected in the event of an incident. It involves implementing a structured approach to identify, manage, and resolve any issues that may arise. Doing so can minimise the impact on your business operations, mitigate risks, and maintain customer confidence.

An incident management plan lets you quickly and efficiently respond to incidents and ensures your systems and applications remain stable and secure. This involves having clear processes, procedures, and protocols for identifying, reporting, and escalating incidents and communicating with stakeholders. By properly managing incidents, you can minimise the disruption to your business operations and reduce the likelihood of any subsequent incidents occurring.

Changes:

Effective change management is a structured approach to managing software and systems development changes. It involves planning, testing, and implementing changes in a controlled and secure manner to minimise the risk of negative impact on the system or business operations.

Change management ensures that all changes are evaluated and approved before implementation and appropriately documented and communicated to relevant stakeholders. By applying change management processes to all software and configuration changes, your company can ensure that its systems and applications remain reliable, secure, and efficient while minimising the risk of downtime, data loss, or other issues that can negatively impact your customers and business operations.

 

CONTROLS AND EVIDENCE

Incidents:

We will look at your incident response plan (DCF-159) to ensure it is effective at pre-preparing your business for an incident. The effectiveness is also verified during your annual incident response test (DCF-154), where you conduct a practical or tabletop test of your incident response plan. A crucial part of a seamless incident response is having a defined response team. In (DCF-29), we will confirm that a response team is in place to handle incidents. To help prevent reoccurrence, lessons learnt during an incident should be documented. We will ensure this is part of your incident procedure in (DCF-30). Employees must have a clearly defined avenue for reporting security-related incidents and concerns (DCF-9). For (DCF-28) we will check a sample of incidents that you have logged, classified, and tracked incidents through to resolution with lessons learned devised to prevent a recurrence.

Changes:

Your software development life cycle policy (change management policy) will be assessed to ensure it defines the software development procedure (DCF-31). Generally, we should see the development workflow documented with critical areas such as tracking, testing, approval and validation of changes, including the approach to test data to ensure the security and confidentiality of production data is maintained. This ties into the code review process (DCF-5), which Drata automatically verifies. We will sample change release/s in (DCF-155) to ensure they were tested and verified before implementation. It is also crucial that authorised personnel independently review changes before deployment to production. This is verified automatically by Drata (DCF-156).

Other resources

  • You can find more information on incidents and the incident management policy here