Specification of Information System Requirements

Answer: Unfortunately we have to apologize about not having a video tutorial about this issue, but to help you fill in this document you can schedule a meeting with one of our experts (some sessions with our experts are included in the toolkit you bought). To schedule a meeting, please access this link: https://advisera.com/27001academy/consultation/

This article will provide you further explanation about defining system requirements:
- How to set security requirements and test systems according to ISO 27001 https://advisera.com/27001academy/blog/2016/01/11/how-to-set-security-requirements-and-test-systems-according-to-iso-27001/

2 - Is this document in reference to the applications that we develop or is this in reference to the tools we use to maintain and develop the applications? The question at hand is what does “Information Systems” reference? Is it the internal applications/tools used to produce our product? Is it the external applications that our clients use, that are developed by us? Could it be both?

Answer: Let's start with the definition of Information systems. For ISO 27001, information systems are software, hardware, databases and any other asset used to store and/or process information.

The purpose of this document is to document all requirements for new information systems, and for improvements of existing information systems, whether they are used internally or by customers.

Considering that, this document is applicable either for systems your organization develops, and for systems your organization acquires, for internal purposes only or to provide to external customers. Your organization can define the range of application in the ISMS scope statement.

3- With internal applications, we can dictate specifically access and security as these systems are only for company use. With external applications, we lose control as while these have specific purposes, the end user dictates the use of these.

If we do apply to external applications, does it apply only to the process to ensure that any work done by us is verified to not to significantly affect the end user’s use, regardless of how they use it? For example, for system XXXX is specifically built for XXXX but we do know that we have at least one client that specifically caters to XXXX. The application is the same but workflows are different.

Answer: As mentioned in the previous answer, this document covers the system's requirements, i.e., what a system can do, what it cannot do, and how it must behave under specific conditions. Specifically for the applications you develop for third parties, the conditions to not significantly affect the end user’s use most probably will come from the end users.