IF zones are used to separate projects or business functions, THEN put systems with like data together and people with like jobs together,
OTHERWISE IF no zone separation is used, THEN put systems with similar risk profiles together and people who have to use those systems together,
OTHERWISE put systems with similar communications requirements together.
ALSO IF a zoned architecture is used, THEN limit subzone content based on management specified risk management thresholds associated with the protective measures in use.
Putting people and data with similar people and data implies that all people with similar jobs and data with similar characteristics require the same level of protection. This is probably a poor assumption for two reasons. The first reason is rather obvious, the same data is used by different people for different purposes, and some of those purposes are far mare critical to the business than others. The second reason is that it defies the notion of separation of duties. Audit information, control information, and submit and commit cycles associated with high valued operations should all be separated, and that is the purpose of zones. Putting like with like within partitions that provide separation is feasible, convenient, and commonly done. However; if separation is only based on projects or business functions, this approach is the only realistic one to use.
Put systems with similar risk profiles together and people who have to use those systems together.
Putting systems with similar risk profiles together is sensible because the risk profile is what should be driving the protection profile. As a matter of efficiency, it is easier to put one instance of a protective measure in place than multiple instances of the same barrier. But this is problematic because (1) similar risk profiles do not mean identical configurations of protective mechanisms, and (2) as risk levels increase separation becomes required for disaggregation. The former problem is very damaging in this approach since the very limits placed on protocols for one application may have to be violated for another. Integrity may be critical for one application while availability is more important to another. Thus risk level alone cannot be used as a basis for separation. However, similar risk level should lead to similar surety requirements on protective measures.
Put systems with similar communications requirements together.
The basis of the layered architecture is what communicates with what. The structure commonly identified in generic terms for large enterprise zoning is based on business sensitivity with increasing numbers of better barriers between increasingly sensitive content and larger volumes of content. In addition, parallel separation of control and audit is used. The particular structure and placement identified here, or a variation on it, is often used in large enterprises as a first level approach to placement because it simplifies management by consolidating requirements and mechanisms. While it sacrifices some surety it does so at substantial cost savings over a component-at-a-time approach. Within this structure, additional structure of the sorts described by the other options is important and should be implemented.
Limit subzone content based on management specified risk management thresholds associated with the protective measures in use.
Risks should be disaggregated above some threshold in every enterprise. Whether it is keeping a backup copy of critical financial data for a small business or requiring separation of duties for large financial transactions for a large enterprise, it is necessary for management to make a determination of how much risk they are willing to group together under common failure modes and what scenarios they are willing to allow to destroy the entire business or what portion of it. However; in a non-zoned architecture, this is not feasible.