Someone proposes entity classes named PCI, HIPAA, and SOX for every regulated workload. What guidance should the implementer give?
Select an answer to reveal the explanation.
Short Explanation
A hospital app can be HIPAA and still be an Application. Laws are content and scope overlays, not the shape of the thing. Class-per-regulation multiplies trees until nothing shares roots.
Full Explanation
Prefer entity classes that describe entity nature—organization, application, facility, vendor—and map regulations through content and scoping instead of creating classes named PCI, HIPAA, and SOX for every regulated workload. Regulation-named classes explode when one application falls under multiple mandates and confuse object taxonomy with obligation libraries. Approving one class per regulation so each law owns a separate hierarchy forever duplicates entities or forces impossible single-regulation placement. Deleting all entities that touch more than one regulation is operationally absurd for civic systems. Replacing entity classes with citation records that generate CMDB hardware collapses unrelated layers of the architecture. Exam caveat: many-to-many citation-to-control-objective mapping is how overlapping regulations share controls—not one class per law. Operational check: reject regulation-as-class proposals in design review; place mandates in authority documents and citations; map to shared control objectives; keep classes nature-based; and demonstrate one municipal application satisfying multiple citations without multiple class homes. Document the pattern in the city's content-architecture standard.