The technological Practices of Integrating Information Securtiy, Change Management and Compliance - Protecting the Deployment Pipeline, and Integrating into Change Management and Other Security and Compliance Controls

9 important questions on The technological Practices of Integrating Information Securtiy, Change Management and Compliance - Protecting the Deployment Pipeline, and Integrating into Change Management and Other Security and Compliance Controls

Which three categories of changes are used in ITIL?

  • Standard changes
  • Normal changes
  • Urgent changes.

Which changes are included in standard changes and how should we deploy these changes?

  • Monthly updates of tax tables or country codes
  • website content and styling changes
  • application or operation patches that have well understood impact

We deploy this completely automated and log for traceability.

How should we proceed for deployment for a normal change?

A normal change should only be deployed if there's a RFC including the go/no go decision.
  • Higher grades + faster learning
  • Never study anything twice
  • 100% sure, 100% understanding
Discover Study Smart

What should be in a RFC?

The desired business outcome, planned utility and warranty, abusiness case with risks and alternatives, go/no go decision and proposed schedule.

What's difference between utility and warranty?

According to ITIL is Utility "What the service does" and warranty "How the service is delivered and be used to determine whether a service is fit for use".

What do we have to do to deploy urgent changes?

These are high risk changes which require senior management approval, documentation can be performed after the fact.
It's a key goal that the deployment pipeline is suitable for urgent changes.

How can we support the assertion that our changes our low risk?

By showing the changes in relation to the production issues over a significant period of time.
Record the changes in the deployment and link them to items in our workplanning.

What can you tell about separation of duty in relation with DevOps?

That reliance on separation of duty should be reduced.
We can use controls like pair programming, inspection of code check-ins and code review.
It gives engineers responsibility for the quality of their work.

What can we do to give auditors en compliance officers the evidence they want?

Integrate the information they need in the deployment pipeline.
For example in version control or a monitoring control of the telemetry.

The question on the page originate from the summary of the following study material:

  • A unique study and practice tool
  • Never study anything twice again
  • Get the grades you hope for
  • 100% sure, 100% understanding
Remember faster, study better. Scientifically proven.
Trustpilot Logo