# Documented Information Documented information is vital to the functioning of the ISMS, as well as being a mandatory requirement for conformity. There are only 14 **required** pieces of documentation, but realistically we need swathes of documentation for an effective ISMS. > ⛵️ Practically speaking to the ISMS as a system of systems, one of the main positive effects of a successful management system is the total organisational acquisition and maintenance of operational information for the area that the scope covers. In effect this means that no meaningful operating procedures or processes exist outside of organisational knowledge (Say for example, in someone's head as lived experience and work wisdom over time). Documentation is therefore a vital function of the system both as an output of processes, and as auditable input for new plans, opportunities for improvement, and evidence of functionality. ![[ISO 27001 Documentation Mind Map.png]] *This diagram is a lift and restyle on a resource from the iso27001security forum, attributed on the homepage* # Clause Mandatory Documentation 1. 4.3 ISMS scope 2. 5.2 Information security policy 3. 6.1.2 Information security risk assessment Procedure and records 4. 6.1.3 (d) Statement of Applicability 5. 6.1.3 Information security risk treatment procedure 6. 6.2 Information security objectives 7. 7.2 Personnel records 8. 8.1 Operational planning and control 9. 8.2 Risk assessment reports 10. 8.3 Risk Treatment Plan 11. 9.1 Security measurements (=metrics!) 12. 9.2.2 ISMS internal audit programme and audit reports 13. 9.3.3 ISMS management review reports 14. 10.1 Records of nonconformities and corrective actions ## How do we keep effective documentation? Standardising documentation seems to be an early investment that helps immensely with process improvement and yields results from the moment you start doing it. Standardising your documentation is a good way to manage things like version control and sensitivity tagging, and can also be uplifted by any automated or large scale solutions you may buy into in the future. Manually however, it's possible to build a simple template in the header or the footer of your document that includes: - Title of the document (Ideally using a standardised naming system) - Sensitivity level of the document - Version of the document, including the date for review of the document - Owner of the document A clausal approach similar to the [[Management System Standards|MSS]] approach may make sense, wherein each document starts with a scope, references, and terms and definitions, before diving into the main content of the policy or document. > 😰 This should not be mistaken to mean that documentation should strive to be the main articulation of your efforts, as too much documentation can be incredibly awkward to maintain. Some things are best left as psychological contracts between workers, it is impossible to document everything, and attempts to capture the minutia of near imperceptible efforts taken by committed contributors tend to exceed the time and labor cost of the value of the contributions themselves. In short - busywork. Bundling documents into a simple folder structure may be sufficient for your needs, but it's likely that the requirement to distribute certain documents and restrict access to others likely means that using a cloud solution will provide benefits such as integrated access control mechanisms to match with data classification. In my experience I've seen some absolutely fantastic implementations in Microsoft SharePoint, and have also heard of proprietary systems that are essentially file management systems with fronting to scaffold conformity with a given MSS. >⛵️ In the end, documentation should only be held if it's providing a utility, and the provision of a unique utility by each document suggests an individuality that requires a standardising system of control and access. An indexed, searchable, and understandable system of document management seems like a near essential component of a healthy ISMS. ## Additional Documentation? Additional documentation may be valuable or essential for business reasons, such as: - Information risk and security strategies, proposals, plans, objectives, status reports and deliverables for implementation or change projects _etc._ - Topic-specific policies, procedures and guidelines relating to information risk and security - Security awareness and training materials, plus the associated attendance records _etc_. - Management information such as the agendas, attendee lists, minutes and actions agreed at ISMS management committee meetings - Operational records generated routinely in the normal course of business (_e.g_. budgets and expenditure reports, log files, audiovisual security footage, approvals, completed forms, lists and databases) or by exception (_e.g_. post-incident reviews, incident notifications) - Compliance with applicable laws, regulations and standards, plus the associated business records such as registration or incident reporting details under data protection legislation - Contracts and agreements concerning security products and services, including internal service level agreements with corporate functions such as IT, HR, Facilities and Risk - Technical materials used for designing, implementing, configuring, training, operating, supporting, monitoring, managing and maintaining systems, including security architectures and designs. The purposes and uses for documentation include: - Capturing (recording) important decisions, inputs, activities and consequences - Facilitating historical analysis such as tracking performance, identifying trends and improvement opportunities - Performance tracking and improvement initiatives - Training, knowledge acquisition and skills development - Demonstrating and providing assurance of compliance and conformity, or indeed the converse (_e.g_. forensic evidence concerning security incidents; incomplete, inaccurate or false/fabricated documents).