ISO/IEC 27000 系列标准阐述了如何创建和管理信息安全管理系统 (ISMS)。ISO/IEC 27001 文件提供了标准的主体，并由许多特定行业的指南文件进行了扩充。
27001 文件包括一个冗长的附件，列出了 114 个控制的完整列表，分为 14 个条款和 35 个类别，可以通过 ISMS 进行审计。
控制 A.9.4.5，“程序源代码的访问控制”规定如下：
对程序源代码的访问应受到限制。
这是否意味着 ISO 27001 与自由/开源软件不兼容，源代码不受限制？
有什么方法可以免除这一点，或者组织生产的任何此类软件是否必须被排除在任何 27001 认证的范围之外？
“应限制访问程序源代码。” 并不意味着没有人应该能够访问源代码，而是定义了谁可以访问和更改代码。重点不是对源代码保密，而是防止对源代码进行未经授权和未经审计的更改。
使用开源也是如此：人们不应该简单地从某个地方导入和使用一些代码或补丁，而不以某种方式确保代码实际上具有预期的行为并且只有这个，即它不包含任何后门并且没有关键错误等。这种“以某种方式确保”并不意味着自己审核所有内容，也可能意味着相信上游发行版和维护者会做正确的事情。多少信任上游或多少自己审查代码当然取决于谁是上游以及使用第三方代码的代码有多重要。
但是盲目地使用 npm、cpan、pip 等安装模块可能是危险的，并且有悖于使用和编写安全代码的精神，请参阅具有高风险的小世界：npm 生态系统或恶意模块中的安全威胁研究——你需要什么在安装 npm 包时知道。
ISO/IEC 27001 安全标准适用于各种组织，其重点是管理体系，因此要符合标准，组织不需要应用所有 114 控制，而是系统地应用风险管理战略侧重于范围内的流程和资产的安全性。
事实上，有适用性声明 (SoA)，组织在其中声明将应用哪些控制，并简要说明如何实施选定的控制，以及对于那些不适用的控制，一个理由，所以，如果组织与 FOSS 保持一致，这应该在 SoA 中进行解释和记录。该文档应支持此控件的选择或其排除。
正如ISO/IEC 27002标准（解释了 114 个控制中的每一个）中所述，这种特定控制的精神是：
... 防止引入未经授权的功能，避免意外更改以及维护宝贵知识产权的机密性。
因此，此控制旨在保护源代码免受未经授权的更改并保护知识产权。
如果选择实施控制，即使组织采用 FOSS，也可以应用一些指导方针，例如：
如果组织使用 FOSS，在源代码的使用中仍然应该有版本控制、变更控制和顺序等内容。这就是这个控制的意义所在。
所有这些指南都需要考虑，不一定要采用或实施。每个组织都定义了要应用哪些控制以及如何执行。
遵守本标准的重要一点是自我解释并遵守组织对每个控制做出的决定。因此，ISO 27001 标准可以与 FOSS 兼容，兼容程度取决于组织所应用的政策和程序的一致性。
话虽如此，很明显，标准的作者在编写规范时并没有考虑到自由/开源软件，可能最初建立这些标准的组织并不专注于 FOSS，而是面向使用 FOSS 的组织可以采用该标准。
在 ISO27001 标准中，没有其他最近声名狼藉的术语，如云计算、物联网或网络安全。该标准与主要标准之后正在开发的 ISO 27000 系列的其他文件进行了补充，希望 FOSS 将包含在后面的文件之一中。