安全管理决策的书中提到，最初的计划制定阶段是提高安全管理的最低费用的阶段。这一观点通常是正确的，但它也隐藏着很多潜在的陷阱。(没有人敢说安全管理很容易，否则他或她会马上被炒掉。)
计划制定阶段通常是工程的相当困难的一部分，如果你没有正确地对待，在之后进行的安全管理将付出严重的代价。当从设计阶段转移到开发阶段，转移到发布阶段，再转移到维护阶段，在每一阶段提高安全管理都会变得相当困难。除此之外，在早期的计划制定阶段，通常只有少数人参与计划制定之中。正确的计划制定能够提高开发效率和减少无休止的程序补丁。
新工程的基本开发规则包括很多有关最终产品价值的通用性，包括产品应该服务的对象，如何维护，如何实现软件等，基于这样的原因，以上的观点看起来似乎违反了一般性。
在一个新工程的最初计划制定阶段中，开发人员都会处理数千行代码，每一行代码都可能成为安全漏洞的地方。即使绝大多数的安全潜在威胁都可以理解到，但是由于很多细节的原因，这些安全威胁通常很难消除。开发人员必须胜任于所有可能问题的预见和完整地使得程序安全化──这很明显是不可能达到的任务。
在设计制定阶段，你可能决定所有数据必须得到保护。这听起来是提高整体安全管理的一条明显和容易的方法，但事实上并不是那样。除非所有的数据都是关键，或者如果被偷窃，将会崩溃整个系统，把所有的数据指定为高级安全等级是一个错误的选择。
我建议我们可以以联邦政府为例，因为它经常将事情弄糟。从联邦安全管理的事情中我们可以吸起一条教训，即将多数数据指定为关键或者高级敏感，结果反而与预期的目标相反。在某些联邦机构中，每一个文档和文件都以最高秘密而标记，虽然很多信息并没有所说的重要。这些会导致商业应用的无法意料的内在结果，比如：
过多的安全管理会造成自我挫败。在多数情况下，只有一小部分的数据需要保护。如果你从开始就仔细地定义数据，那么很多人都需要最高访问等级的权限。
从开始阶段起，在一个程序中建立安全管理应该是提高程序安全的低费用和高效率的方法，但粗心大意的计划也会使得安全系统变得不安全，因为安全管理取决于开发人员自身。例如，由于一些低级的说明，用户实现他们的需要的唯一方法是偶合使用管理员的权限，然而最终每一个人都会每次都使用最高访问等级，这样就会降低整个系统的安全性。
这只是一个假设，但是，如果你想对更多的数据进行安全化，数据的安全性会变得越差，因为这样会有更多的人获得访问数据的权限。这也就是明确选择安全管理决策的原因。
