ISMS interfaces and dependencies

Answer: Interfaces are the limit points between what is inside the ISMS scope and what is out (e.g., a website page is an interface between organization's information systems and the external public, a loading area is an interface between a supplies and the organization, etc.).

Dependencies as relations between organization's elements (processes, assets, etc.) that are needed to achieve a defined outcome (e.g., a datacenter depends upon a communication provider to make information systems available).

This article will provide you further explanation about examples of interface and dependencies:
- How to define the ISMS scope https://advisera.com/27001academy/knowledgebase/how-to-define-the-isms-scope/

These materials will also help you regarding examples of interface and dependencies:
- Book Secure & Simple: A Small-Business Guide to Implementing ISO 27001 On Your Own https://advisera.com/books/secure-and-simple-a-small-business-guide-to-implementing-iso-27001-on-your-own/
- Free online training ISO 27001 Foundations Course https://advisera.com/training/iso-27001-foundations-course/

Sir,
Can you please put some light on these two scenarios:

1. I've created a webpage, which is hosted on servers of organisation A. Webpage is just a GUI, at the backend, we're utilising the services of SAINT... basically, our organisation provides customers a GUI and paying SAINT for the services going on the back of our webpage.
Can you please point out any interfaces and dependencies involved here?

2. We're using a product called Alienvault, for the SOC analysis. In our organisation we have terminals for analysis ( traffic, vulnerabilities in system etc) . At our customers end we have installed Alienvault software at some nodes. All the logs resides on the servers of Alienvault.

Can you please help me figure out the interfaces and dependencies in both the scenarios above????

For scenario one, if I understood correctly, your GUI is a product delivered to your customer, as well as the SAINT services. So, at least you have two interfaces:
- The interface you use to deliver the GUI to your customer (e.g., your organization's web page, a FTP server, etc.)
- The interface you use to pay for SAINT services (e.g., SAINT's webpage, an Internet Banking site, etc.)

As for dependencies, some examples may be a communication's provider and your IT infrastructure.

For scenario two the main interface would be the Alienvault product itself (which provides you connection with both your terminals for analysis and customer's nodes). As for dependencies you would have communication's provider, your IT infrastructure, and software's manufacturer support.

According to that, An Office Door is an INTERFACE while biometric device used to enter the office is a DEPENDENCY... Similarly, FIREWALL is an INTERFACE and Firewall Company Support is a DEPENDENCY.. Am I right?????

If all your scope is behind that door, than yes, the Office door is an interface. Regarding the dependency, it would be better to consider the access control system (the biometric device may be only one element - if it is network connected, you also have the network, access control application servers, etc.).

For the firewall example your thinking is right.

Thanks a lot for the clarification. Actually, I'm preparing a table for interfaces and dependencies. can you suggest any format??
I thought of this-> TABLE 1
Column1. Internal Provider(OLA) [eg. HR]
Column2. Name [ eg. HR Manager]
Column 3. Interface/dependency [ eg. Hiring employees, Termination etc.]

TABLE 2
Column1. External Provider(SLA) [eg. SIEM]
Column2. Name [ eg. Alienvault]
Column 3. Interface/dependency [ eg. Alienvault Support, ISP, IT Infra]

Is this a good Idea? any different format that you like to suggest

In fact, ISO 27001 does not require the interfaces and dependencies to be documented (only to be considered when defining the scope), so documenting them because of the standard only would create an additional document to be managed without need. On other situations where documentation of interfaces and dependencies may be required, the way to document them should be considered on a case by case basis (e.g., network interfaces and dependencies are better described in a network diagram, services interfaces and dependencies in SLA's, activities interfaces and dependencies on process workflows, etc.)