iso27DYI Product Requirements Document (PRD)

Product

iso27DYI is a web application that offers guided application of the ISO 27001 framework. The purpose of the system is to guide the ‘Client’ in the implementation of an ISO 27001 compliant Information Security Management System (ISMS), and store all the proofs of implementation, so that the Client can pass the ISO 27001 certification audit successfully.

Design Guidelines

The goal is to build a fully functioning system as described below. We will start with a MVP release and expand and refine on that. The functionality of the MVP release has not been defined yet, neither has the release planning of road map.

Pointers:

iso27DIY assumes the user has no a priori knowledge of cybersecurity management or ISMS's
iso27DIY guides the client in what to identify, assess and produce, how to do it, and in what order
iso27DYI's guidance will feel like a smartwatch fitness coach, rather than having the user walking down checklists
iso27DIY provides best practice examples and generates compliant content based on the user's input
iso27DYI will help the client with building the necessary capabilities to maintain the ISMS within his own organization
the content will be organized in Modules, with each module consisting of one or more Sessions
the route through the modules is incremental rather that linear (though there are information-dependencies between the modules) – artefacts will be expanded as needed, to facilitate the integration of the ISO 27001 framework in the client's business and management processes (example: incremental RASCI matrix).

Client and User

The Client is typically an SME, with no dedicated compliance officer and little knowledge of information security management and the ISO 27001 standard. The ‘User’ is the person made responsible for implementing the ISO 27001 standard within the SME. He or she is typically employed as the ‘IT Manager’ or COO.

Some words about the ISO 27001 standard

The ISO 27001 consists of a prescribed process for managing security risks (the ‘Management System‘), and a number of risk mitigating measures (‘Controls’) that must be implemented to mitigate those risks. According to the ISO 27001, the structure of the management process and its constituent steps, must be described as ‘Policies’. The implementation of the Controls must also be described in Policies. Furthermore, the ISO 27001 requires Proof of implementation. This can take the form of policies, guidelines, manuals, logs, minutes, plans, reports, classifications, etc. There must be evidence of a PDCA cycle being continuously applied to the management system and it’s controls.

The iso27DYI system

The system contains of three main parts: the Guided Implementation System (GIS) that helps the user to identify, collect and create the Proofs of implementation of the ISMS and its controls, the GRC tool (called ‘AuditGlue’) to store and manage these Proofs, and the Knowledge Base, which supports the identification and generation of Proofs.

Guided Implementation System

The GIS (Guided Implementation System) takes a User step by step through the implementation of the ISO 27001 management process and its accompanying controls. The implementation is divided into several ‘Modules’, each consisting of several ‘Sessions’. In each Module and Session the User is introduced to the topic at hand through a mixture of videos and texts. The User may be asked to provide information that is relevant to the topic. This happens through a stateful dialogue with a proactive conversational agent. The task of the agent is to fill predefined data slots. The User must have the option to request further explanation, examples either general or specific to the type of Client organization or business process, and support by a Consultant. Support (for implementing the ISMS, not for the usage of the system) is given by an LLM Chat Agent, but can be ‘escalated’ easily into a request to get support by a human consultant.

Modules and Sessions do not necessarily have to be completed sequentially, but in some cases a Module or Session may be dependent on the information gathered or outcome produced in earlier Modules or Sessions. The progress of the Client and User is visualized in a simple and attractive way, both for progress through Modules and Sessions and for progress towards ‘certification readiness’.

The Modules, Sessions, and content elements of the GIS will be tagged with identifiers referring to the controls and clauses of the ISO 27001 standard (not by the user but through the management interface, see below).

The GIS produces artifacts by combining the user’s input with its internal knowledge base. These artifacts may be example Proofs of implementation (as mentioned before), or tailored plans and action lists to construct these Proofs or collect them if they may already be present in the organization.

All inputs and artifacts are stored in the AuditGlue database.

The content (text, videos, questionnaires, etc.) that is made available to the user through the GIS are the intellectual property of Thinking Security Works, the company behind iso27DYI. The architecture of the system must prevent this content from being copied or altered by Clients, Users or other parties.

AuditGlue

AuditGlue is used to store and manage all inputs and artifacts collected or generated through the iso27DIY Guided Implementation System, plus additional artifacts the User deems relevant to the ISO 27001 certification audit. Inputs and artifacts collected or generated through the iso27DIY GIS will be tagged with (roughly) the same identifiers as the Module or Session through which they where collected or generated. Additional artifacts added by the User must be tagged by the user with at least one of the ISO 27001 related identifiers. The user is provided with a mechanism for creating and managing their own tagging system, additional to the ISO 27001 related identifiers provided by the system. The contents of the AuditGlue database may be altered by the user. Version management is implemented for CRUD actions on the content. User may compare different versions of the same documents to show the differences. AuditGlue provides Auditing Views on the contents of the AuditGlue database to support the auditing proces, following the structure of the ISO 27001 standard.

The Knowledge Base

The user input is used to build a knowledge base about organizational structures, processes, policies, risks and measures related to information security and compliance. This knowledge base is then used to improve the quality of the interaction with users (e.g. asking questions more specific to the context of the user and his type of organization). The knowledge base is not accessible to the User.

Management interfaces

Management interfaces must be added to the system to allow employees of Thinking Security Works to:

Manage the contents of the GIS
Construct questionnaires and add them as contents to the GIS
Manage system tags and attach them to the contents
Manage Users and allow access to functionality based on their Plan.

Functional Diagram

iso72DYI Technical Requirements

The system must support multiple Clients, with each client having one or more Users. It is essential that no Client, or any of its Users, ever gets access to another Client’s data. This must be implemented at database level.
The system uses a combination of structured questionnaires, forms, document ingestion and chat agents to acquire user input.
The system uses templates and LLM to generate artifacts. These artifacts consist of text and simple graphics (bitmap images). Output formats are Markdown, DOCX and PDF.
Onboarding must be handled on the iso27diy.com website and should be as frictionless as possible.

Leading Principles

languages, frameworks, technologies and platforms must be selected to maximize security, portability, maintainability and scaleability (roughly in that order)
current preferences are JavaScript/TypeScript, SQL, JSON/JSONB/JSON Schema, SurveyJS, Postgres
the source code will be available under a, yet to be decided, OSS license
third party code and frameworks that used in the system must be available under OSS licenses that allow commercial use without licensing fees
dependencies on third party code must be kept to a minimum
the number of deployment platforms (data layer, application logic, front end) must be kept to a minimum
user authorization and payment services will be handled through vested service providers
the LLM(s) must be deployed ‘locally’
deployment costs must be acceptable (funds are limited)
architecture, source code and deployment methods must be well documented throughout the project

8.8 KiB Raw Blame History Unescape Escape