A Lightweight Information Security Management System (Part III)

Projects

Now that we have our policy in place, we need to get it to do some work for us.

Implementing security policy takes time, and should definitely not be done all in one go. You’ll overwhelm the team and yourself that way, and probably disrupt ongoing development and operations.

Implementing policy can be especially tricky if the development and operations teams are under pressure to deliver features (which they usually are).

At E-accent, we would have “messy sprints” between the standard development sprints (in Shape Up, these sprints are called “cool down periods”). During “messy sprints”, we would deal with loose ends like bugs, refactoring, and non-development tasks. Perhaps you could try to introduce them at your company.

A good first policy to implement is the Inventory of Assets. This shouldn’t take much time, and knowing where data is stored is a great starting point.

Procedures

In information security, it is important that all processes are repeatable. That’s why we make use of standard procedures.

For example, if you want people to go through the security settings on their computer, you all want them to check the same settings. It doesn’t make sense if some developers encrypt their hard drives and others don’t. If your security policy is applied randomly, it is far less effective and hardly measurable.

Each procedure needs to be written by someone senior in the role that it applies to. For instance, incident management procedures should be written by a senior operations person.

How to use procedures

In our ISMS, a procedure is a template for a job.

Let’s say that a user is scheduled to do the 3-monthly Information security policy review.

First, she creates a copy of that procedure, which becomes the job. She checks off the tasks of the job, dates and signs it, and stores it into the ISMS as a record.

When to use a procedure

A procedure can be triggered by:

• a timed event on your calendar,
• an incident, for instance a server going offline,
• another one-off event, like the onboarding of a new team member.

The tricky part can be for ISMS users to remember that they need to use a procedure.

If a procedure is missed, we speak of a non-conformity (more on that later).

Example of a simple procedure

Let’s consider this example policy:

All team members shall carefully review this information security policy once every 3 months, ask clarification where needed, suggest improvements if applicable, and finally confirm in writing to the product manager that the policy was read and understood.

We could create a procedure document “Information Security Policy Review” that would read as follows:

Please review the security policy document at [link to document] carefully.

If anything is unclear, please reach out to the product manager for clarification.

[ ] I declare that I have read and understand the ISMS policy document.

Name: ___________________

Date: ___________________

Signature: _________________

This completed job is stored in the ISMS as a record.

Records

We already touched upon records above.

Since our ISMS is part of an ongoing learning process, we need to keep a record of everything we do. Records provide us with the data that we need to measure improvement.

You want a record of anything that happens in the ISMS:

• every time a procedure was used
• every time that anything was changed in any of the core documents (policy etc)
• every time a non-conformity happened

For instance, if a procedure is structurally not used, and you are working with the development team on a different approach, you want to be able to compare the situation before and after.

You may store records in their own separate place in the documentation system, but there is something to be said to split the policy document into individual pages, and store records right underneath each policy item.

Non-conformities

We’re speaking of a non-conformity whenever an expectation (policy) of the ISMS was not met.

In that case, you’ll want to log a non-conformity.

A non-conformity document contains:

• the date
• which expectation was not met
• the user who was responsible
• how it happened
• if/how the problem was corrected (correction)
• how the problem is going to be prevented in the future (corrective action)

Now, keeping track of non-conformities can be quite confrontational, and I would not start using them right away. Make sure to have a grace period in which non-conformities are not recorded, just discussed with the team.

Having a grace period allows people not only to get used to security policy, but also to provide feedback on procedures and policies. Procedures that look great on paper might turn out to be a real pain in the butt when used in practice. You’ll want to make them as usable and useful as possible before turning tough on the development and operations teams.

That is all!

I hope this was useful. I’d love to hear your experiences. Please drop me a note with any questions or comments!