In this lesson,
we're going to discuss documenting changes.
Now, documenting our changes is one of the cornerstones
of an effective change management process.
When we document our changes, we're not focused
on just introducing a change into our environment,
but we're also going to be focused on creating a clear record
of what was done, when it was done, and why it was done,
to ensure that we have both accountability
and a roadmap for our future reference.
Now, when it comes to documenting changes,
we're going to be looking to ensure
that version control is actually happening,
that proper documentation updates are being performed,
and that maintenance of various associated records
is being completed as needed.
Now, first, we have version controls.
Each change we implement
can carry with it numerous other changes,
or impacts on your systems and networks.
Version control is the safety net that ensures
our changes do not create more chaos.
Every document, software, and other files,
should use version control
to prevent us from losing sight of the big picture.
Version control is basically just a system
that tracks and manages changes to our documents, software,
and other collections of information
to allow multiple users to work collaboratively
and revert back to a previous version whenever it's needed.
Now, by maintaining different versions of documents,
software, and other files,
cybersecurity professionals like us
can track the evolution of a given project
and its associated changes.
If an error occurs
or implementing the rollback plan becomes necessary,
version control allows our teams
to revert to a previous more stable version
of a given piece of software,
system configuration, or network architecture.
Our goal with version control
is not to simply preserve the past iterations or history,
but it gives us a centralized place
where we can help ensure the continuity
and stability of our environment over time.
Second, we have the need for proper documentation.
Now, whenever a change is being implemented,
its accompanying documentation should also be updated
to reflect the implementation of that change.
Regardless of whether we're changing
a minor configuration setting,
or we're performing a major overhaul
of our network infrastructure,
every change needs to be properly documented and recorded
by updating our diagrams,
revising our policies and procedures,
and updating change requests
at any associated trouble tickets.
Updating our diagrams is an important step
because these diagrams provide us
with a visual representation,
like a flow chart or network diagram
that provides us with a snapshot
of our system's architecture.
After any change is implemented,
you and your team must take the time to update your diagrams
to ensure they still accurately reflect
the current state of your systems.
Many people simply ignore this step
because they think they're going to remember
all these changes in their head,
but I can tell you from experience,
this is a recipe for disaster.
Remember, this isn't just a small home network
that you're going to be working on,
it could be a network that spans across your city,
your state, your country, or even across the world.
To run networks on that scale,
you're going to be working as part of a team,
and so if something isn't properly documented,
then nobody else on the team
will know what changes you've implemented,
and this can lead to a lot of misunderstandings
and misconfigurations.
After you implement your changes,
you should then stop and ask yourself,
did everything go perfectly?
What could we have done better?
This is an important step
because not all changes are going to occur smoothly
and without incident, so if there's any issues,
you may need to go back and revise
or update your policies and procedures
to account for those issues.
Whenever you find an issue in your change implementation,
it is important that you don't just rectify
the immediate issue, but also take some time
to go back and figure out
how you can revise the associated policies or procedures
to prevent the same kind of issue from happening
in the future.
This form of continuous improvement
relies on the iterative process improvement
that is going to ensure your past mistakes remain in the past,
and that your future changes are smoother
and easier to implement moving forward.
Now, once your change is successfully implemented,
the associated change request or trouble ticket
should also be updated to reflect the successful completion
of that proposed change.
This is not just a bureaucratic step though,
because it's actually going to provide you with a way
to create a clear timeline of the change actions
and to ensure that all of your stakeholders
are being informed of the change,
and that there's a record of the change history
for future reference.
So remember, documenting changes
is more than just an administrative task,
it's a vital component of effective change management.
To effectively document our changes,
we must ensure that version control is occurring,
proper documentation updates are being performed,
and the maintenance of various associated records
is being completed to ensure clarity
and accountability of our change actions.
In our modern systems
that rely on massive amounts of interconnections
through partnerships and the use of APIs,
the proper documentation is going to allow us
to be able to be guided as cybersecurity professionals
through the intricate maze of systems,
applications, and configurations
that we use on a daily basis
so that every change, no matter how minor it is,
will be clearly and precisely implemented
within our organization's networks.