Policies are needed for the security of the project. If policies are not applied properly there is no guarantee that the users are safe. If users aren't safe they can be exposed to EAVESDROPPING, SECURITY BREACHES, INFORMATION LOSS, INFILTRATION, EXPOSURE TO ROUGE ENTITIES, PERSECUTION and LOSS OF LIFE AND WEALTH. Policies are numbered according to a certain format for description and implementation reference, this is very important for viability. Policies are classified into layers of rings and sections, each policy has a serial number chronologically according their implementation.
Example: 1A-0001 Policy description and purpose.
- 1: Fields
- A: ...
- B: ...
- 2: Documents
- C: ...
- D: ...
- E: ...
- 3: Portfolios
- F: ...
- G: ...
- H: ...
- J: ...
- 4: Facade
- K: ...
- L: ...
- M: ...
- N: ...
- 5: Nodes
- P: ...
- Q: ...
- R: ...
- S: ...
- 6: Domain
- T: ...
- U: ...
- V: ...
- X: ...
- 7: Network
- Y: ...
- Z: ...
0I-0000: Null policy. This policy should never happen, it indicates an implementation failure or different error.
1A-0001: Check that a field marked as required isn't empty. Required fields are mandatory.
1A-0002: Check that multifield isn't assigned non-list items directly, this goes both ways. A multifield must have a list.
1A-0003: Check that a field is assigned an item of a specified type only. The specified item types are required