A Lightweight Information Security Management System (Part II)

In part I of this article, we discussed why your application needs to be protected by information security policy, also (and especially) when security awareness at the organisation’s management is lacking.
In this part II we’re getting the core documents in place.

Create the necessary documents

In your documentation system, create the following documents:

Per document, I’ll shortly discuss its contents, and provide example copy to get you started.

Information Security Objective document

The Information Security Objective document explains to users of the ISMS why it exists, and what we want to achieve with it.

For example:

The objective of this information security management system (ISMS) is to reduce the risk of loss of confidentiality, integrity or availability of the HelloWorld application’s data, source code, and documentation.

Now that we have the objective in writing, we can use it as validation for every new policy that we’re going to include in the ISMS. Does this new policy serve the information security objective, yes or no? If yes, it’s in, if no, it’s out.

We need to make this document available to all users of the ISMS, so that everyone can remind themselves at any time of the importance of what they’re doing. It also allows them to challenge a policy if they believe it does not make sense.

Users of the ISMS

The users of the ISMS are all actors who are supposed to carry out the information security policy.

Some parties who have a responsibility in your information security are not users, for instance if they’re working for a different department or organisation. In such case, they are considered suppliers, and you need to have their responsibilities formulated in your Supplier Policy, and have those agreed upon in a contract.

Example copy:

Users of the ISMS shall be:

The product manager shall be responsible for:

Team members shall be responsible for:

Information Security Policy document

The Information Security Policy describes the means by which we achieve the information security objective.

A policy is a set of promises. We are going to live up to those promises by following procedures (and keeping a journal so that we have records of what we did).

Let’s go through the chapters one by one:


Example text:

This policy document lays out what we are going to do in order to achieve our information security objective.

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.

Now create:

Location of information

Example text:

Now create:

Application vulnerabilities

Example text:

Now create:

System vulnerabilities and availability (Operations)

Example text:

Now create:

Application hosting location

Example text:

If you are not sure where production and backup systems are hosted, create:

If they appear to be hosted in a different jurisdiction, create:

Production data

In this example copy, I’m assuming a relatively low level of criticality of the data - in other words that we’re not dealing with financial or health records. (In those cases, you need a full-blown ISMS anyway.)

Now create:

Backup systems

Example text:

Disaster recovery

Example text:

Workplace security

Example text:

Authentication policy

There are too many options here to give you example copy, so you’ll want to discuss the options with your development and operations teams and possibly the service that you use for the regular security testing.

In general, you need to consider the needs and responsibilities of the general public, “power users” and developers/operations.

The general public is used to authenticate with usernames and passwords, which unfortunately are very insecure and get compromised all the time. Strong passwords offer few benefits, although it’s probably a good idea to disallow users to create top-100 common passwords like “password123”. 2-factor authentication via email or text message does little to improve things, and in some cases might actually make things worse.

If security for the general public is important, consider one of the more modern implementations of passwordless authentication such as Apple’s Passkeys, but be aware of the users’ unfamiliarity with the technology and make sure to guide them through the process gently.

For power users, you’ll probably want some hardware-key based security, and also a good web application firewall is important.

Developers and Operations should use the strongest authentication methods available, like public key authentication in combination with a passphrase. Hardware-key based authentication is a good idea as well. This won’t be a problem as developers and operations people are familiar with all those methods.

I’ll write a separate article on this topic soon.

Protection of personally identifiable information (PII)

Residents of the EU, California and other jurisdictions have the legal right to:

This right is independent of where the organisation that processes the data is stored. So even if your organisation is based in New York, you are subject to EU and California legislation as soon as you have data on EU or California residents.

Especially the implementation of PII deletion can be a bit complicated.

Even if you don’t have PII of EU or California residents in your database, it might still be a good bet to be prepared for privacy requirements. Especially since EU and California legislation is being used as a model by other countries, even China.

Perhaps the following example copy could be useful:

Supplier policy

Example text:

Security awareness training

If your organisation has low security awareness, it might be difficult to get funding for proper security awareness training.

In that case, you might just set aside some time for self-study, using free resources:

That is all for Part II!

We have now covered the core documents of your ISMS!

In part III of this article, we are going to cover procedures, records, non-conformities and project management.

Stay informed of new posts?

Sign up below and you will receive a weekly digest of new posts.

If you change your mind, you can unsubscribe at any time. You will not be spammed, and we will keep your email address private.

Article index