Rather than attempting to manage a mountain of paper documents, declare the electronic online versions definitive.  Set up a suitable structure for the ISMS materials (strategies, policies, procedures, guidelines, training courses, awareness content, reports, metrics ...) in a communal area (such as your intranet or LAN)  with controlled access.

It is worth developing a consistent style and format (a.k.a. 'look and feel') for each type of ISMS-related material.  Consistency helps bind them into a coherent, professional suite.  Parts of the ISMS are inevitably formalised (e.g. policies), whereas others can usefully be more user-friendly (e.g. guidelines). 

Review and maintain the documentation continually. 'Spring clean' occasionally to address out-of-date or inconsistent materials and identify gaps or improvement opportunities.

Do you have a logo with which to ‘brand’ your ISMS-related documentation?  If not, an internal competition to generate one is a little security awareness opportunity!

That's up to management. 

See ISO/IEC 27002 for a decent outline of what the policy (or rather policies) should cover, as a minimum.

A hierarchical structure is common:

• At the tip are a few fundamental principles or axioms - things such as 'least privilege' and 'CIA triad' perhaps, or risk management and accountability, or minimising the number and severity of incidents, or whatever.  In a sense, these are your top-level information security objectives.

• Next comes some sort of overall corporate information risk and security policy - an overarching statement by senior management regarding the principles, mandating and explicitly supporting the ISMS for the business as a whole (or at least the area in scope). 

• Individual policies covering specific information security topics or issues (e.g. “Email security policy”, “Network access control policy”) tend to be quite formal but need not be stilted. Typically they: specify security responsibilities; offer explanations to aide reader comprehension; reference/link higher and lower levels of the hierarchy, binding things together; are general/technology-neutral; and are succinct - ideally no more than a few pages at most. 

• Corporate security standards expand on the high-level policies with technical details needed for their implementation e.g. a standard for 'Windows desktop security' would typically specify Windows security parameters and activities such as patching, antivirus, backups, logging, alerting etc.  Standards (both corporate and public) can be used as criteria for technical conformity assessments, including automated checks, and guide the security aspects of provisioning and configuring new systems.

• The base level consists of procedures and guidelines, plus advisories, course materials, awareness content, newsletters, blogs and so forth - stuff to help people understand and make good use of the policies, standards etc. 

Just 14 (yes, seriously, just 14) types of document are mandatory in the sense of being formally required of every organisation seeking certified conformity to ISO/IEC 27001:

1. Clause 4.3 - ISMS scope

2. Clause 5.2 - Information security policy

3. Clause 6.1.2 - Information security risk assessment procedure

4. Clause 6.1.3 (d) - Statement of Applicability

5. Clause 6.1.3 - Information security risk treatment procedure

6. Clause 6.2 - Information security objectives

7. Clause 7.2 - Personnel records

8. Clause 8.1 - Operational planning and control [see below]

9. Clause 8.2 - Risk assessment reports

10. Clause 8.3 - Risk Treatment Plan

11. Clause 9.1 - Security measurements (=metrics!)

12. Clause 9.2.2 - ISMS internal audit programme and audit reports

13. Clause 9.3.3 - ISMS management review reports

14. Clause 10.1 - Records of nonconformities and corrective actions

Some on the list may consist of multiple items (e.g. a set of topic-specific policies), and some may be combined (e.g. risk assessment and treatment can be covered in a risk management policy, procedure or guidelines).  Furthermore, the ISMS auditing standard ISO/IEC 27007 notes that:

• There should also be a documented audit process sInce the definition of 'audit' states that it is a 'documented process';

• Clause 7.5.1(b) requires 'documented information detemine by the organization as being necessary for the effectiveness of the ISMS' - a rather vague and open-ended requirement that the organisation needs to interpret and satisfy for itself.  Read on.

In practice, most organisations choose to prepare and incorporate rather more than those mandatory items, for business reasons. There are usually many more discretionary documents such as:

• Those needed to justify, manage and track the typical ISMS implementation project, plus ISMS changes and various other substantial infosec-related activities;

• Info regarding governance of the ISMS e.g. structure charts/organograms, descriptions of ISMS-related roles and responsibilities, broad principles, axioms and imperatives;

• ISMS management information - various strategies, metrics, reports, plans, budgets etc.;

• Docs concerning the information risks, as generated by the risk management process; and, most numerous of all ...

• Docs concerning the organisation’s information security controls, such as policies, procedures, guidelines, parameters, lists and databases, operational information, reports, logs, event records, alerts and alarms, diagrams, help text ... lots of stuff here!  

ISO/IEC 27001 clause 8.1 says “Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned.”  In theory, someone could become confident without any written records (e.g. by directly observing ISMS activities as they are performed) but the absence of readily-auditable evidence would undoubtedly upset the certification auditors in practice. They typically expect to review all the mandatory documentation and sufficient discretionary items to confirm that the ISMS both conforms with the standard, and is operating as documented.

Before you get carried away by the thought of 'all those docs', remember that your primary objective is to manage the organisation’s information risks and security controls effectively and efficiently for sound business reasons, not to generate and manage reams of red tape, accumulating unnecessary burdens and costs. 

The KISS rule applies: Keep It Simple and Straightforward.  Less is more.  Get a grip.

Starting with the 14 mandatory ISMS documentation types, do you really need reams of detail or will brief summaries suffice? Who actually needs to read and understand them?  Who are they for? What are the objectives or purposes?

Next the discretionary docs: again, don't go bonkers with the keyboard. Keep them short and sharp where that makes sense.  In particular, be sure to document what you actually do, not what you think perhaps might be quite nice to do possibly in an ideal world. Clearly distinguish mandatory or obligatory activities by using keywords such as 'shall' or 'must', leaving weasel-words such as 'appropriate', 'if necessary', 'ideally', 'should' and 'may' for the remainder.  

Some documentation (such as details of applicable legal and regulatory obligations, or health and safety requirements that are relevant to information risk and security) may be better managed outside the ISMS (e.g. by your legal/compliance and HR or H&S teams, respectively).  That's a scoping issue.

So, given all that, do you actually need a 'system' to manage ISMS docs, or can you get by with the simple tools and processes to hand?

No, neither, at least not if you are thinking of a thick physical book or lever-arch file full of policies, procedures etc.

Electronic documents are preferred.  However, it is worth cataloguing, introducing or outlining, and referencing your policies and other ISMS documents somewhere e.g. in the ‘Security Zone’ on your intranet. As well as making it easier to keep important documents accessible and under control, the certification auditors will appreciate having a neat list of the key ISMS documents, and you will have a handy shopping-list of the docs the auditors are most likely to ask for.

For bonus marks, identify the document owners, plus the issue and revision status if that helps keep the materials reasonably up-to-date – not just for the sake of it though. If your document management policy states definitively that ‘policies must be reviewed and re-approved every year’, even a single, trivial example of a slightly out-dated policy is potentially an adverse audit finding.

Regarding corporate policies, procedures and the like, shorter and more succinct is almost always better.  It means less to:

• Write;

• Review, consider, check out, discuss ...;

• Approve;

• Implement i.e. mandate, circulate to the relevant people and put into practice;

• Read and understand;

• Train people about or at least make them aware of;

• Police i.e. check/ensure compliance/conformity with, and audit against; and

• Maintain.

That's quite a burden when you think about it, costly too.  Minimisation makes sense but there are practical limits. The documents need to be sufficiently comprehensive to meet your organisation’s particular risk mitigation needs, expansive and clear enough not to be totally cryptic, and need a certain gravitas to be considered by management and staff as actual policies.  

A single policy stating something like “Keep all our information assets secure” or "Don't be evil" scores very high on the succinctness scale but very low on the “What on Earth am I meant to do to comply with this policy?” scale!

ISO/IEC 27002 guides you on the sorts of controls you ought to consider in the specific area you are working on. It makes sense to use the standard as a basis, a starting point. See how well it fits your organisation’s needs (considering your particular risks, circumstances and other supporting controls), modify it as necessary, then implement your policy ... and finally drop into ‘maintenance mode’ where subsequent practice, incidents, near misses and any changes in the security threats and vulnerabilities or business impacts in that part of your ISMS imply the need to change your controls.

Your policy development process will, in time if not already, come up against the challenge that many potential subject areas could be covered by multiple policies, looking at similar issues from different angles. “Working in secure areas”, for instance, begs obvious questions about what constitutes “working” (do you mean just employees on the payroll, for instance, or does it apply to contractors and cleaners?), and how you have identified and defined “secure areas” (is there a physical risk assessment process?). You can carve up all your controls in numerous ways, and (trust me!) it is very easy to end up with a totally unworkable mess of overlapping, conflicting and yet gappy policies if the overall policy development process is not itself well managed. 

So, think and plan ahead, using standards such as ISO27k and the NIST SP800s as a basis for your policy set.  

If your Statement of Applicability conforms to ISO/IEC 27001 clause 6.1.3d, it will list the 'necessary' and 'unnecessary' [information security] controls in scope of your ISMS along with the specified justifications and implementation status. You may consider some or all of this information to be sensitive since sharing it increases the risk of inappropriate access and perhaps exploitation.  

On the other hand, not sharing it (being reluctant or flatly refusing to disclose it) increases the risk that third parties such as business partners, investors, authorities, customers and prospects may decline to engage and do business with your organisation.  Your reluctance to provide assurance that various unacceptable information risks are being duly mitigated could be a barrier, indicating limited trust.  If you decline to share it with the certification auditors, your conformity certificate will almost certainly be refused. 

So, in ISO27k terms, these are simply information risks for management to evaluate and treat in the normal way, using the risk management processes in your ISMS.  If certification is important to the business, some degree of risk is inevitable: the trick is to manage it in the best interests of the organisation, overall.  

Consider for instance:

• Who should or should not see your SoA?  Why them?

• What are the requirements or expectations of the intended recipients?  How will they use the information - what for?

• What are the implications of inappropriate disclosure?  How significant are the impacts?  How likely is this to happen over a realistic timescale?  

• What information must your SoA contain, exactly?

• Can it be phrased discreetly or in such a way that the most sensitive details are witheld or provided separately only if appropriate?

• Can you reasonably restrict its sharing and onward disclosure by legal or other means, such as through binding non-disclosure agreements?

• If the preventive controls partially or completely fail, what security options remain? How can you detect and respond to inappropriate disclosure?