{ "meta": { "version": "sha256-93cc6df60db45c423ba9b695651c95b973d23e3ab5fbf22358464ee71dfc7c19", "name": "Keel compliance crosswalks", "description": "Canonical, framework-agnostic security and quality controls, each mapped (crosswalked) to the clauses it satisfies across multiple compliance frameworks. Maintained by Keel.", "source": "https://keelgrc.com/open-source/", "license": "CC-BY-4.0", "attribution": "Keel GRC LLC (https://keelgrc.com)", "controlCount": 283, "frameworks": [ { "key": "ai-governance-essentials", "name": "AI Governance Essentials" }, { "key": "amazon-child-directed", "name": "Amazon Appstore Child-Directed Apps" }, { "key": "apple-kids", "name": "Apple App Store Kids Category" }, { "key": "cis-controls", "name": "CIS Controls" }, { "key": "coppa", "name": "COPPA" }, { "key": "esg-essentials", "name": "ESG Essentials" }, { "key": "eu-ai-act", "name": "EU AI Act" }, { "key": "fedramp-20x", "name": "FedRAMP 20x Key Security Indicators" }, { "key": "fedramp-rev5-class-b", "name": "FedRAMP Rev5 Certification Class B" }, { "key": "fedramp-rev5-class-c", "name": "FedRAMP Rev5 Certification Class C" }, { "key": "fedramp-rev5-class-d", "name": "FedRAMP Rev5 Certification Class D" }, { "key": "fedramp-rules-2026", "name": "FedRAMP Consolidated Rules for 2026" }, { "key": "gdpr", "name": "GDPR" }, { "key": "google-play-families", "name": "Google Play Families" }, { "key": "hipaa", "name": "HIPAA" }, { "key": "iso-27001", "name": "ISO/IEC 27001" }, { "key": "iso-42001", "name": "ISO/IEC 42001" }, { "key": "iso-9001", "name": "ISO 9001" }, { "key": "nist-800-171", "name": "NIST SP 800-171" }, { "key": "nist-800-53", "name": "NIST SP 800-53" }, { "key": "nist-ai-rmf", "name": "NIST AI Risk Management Framework" }, { "key": "nist-csf", "name": "NIST Cybersecurity Framework" }, { "key": "pci-dss", "name": "PCI DSS" }, { "key": "pipeda", "name": "PIPEDA" }, { "key": "soc-2", "name": "SOC 2" }, { "key": "sox", "name": "SOX (Sarbanes-Oxley) Section 404" }, { "key": "us-employment-federal", "name": "US Employment Law (federal baseline)" } ] }, "controls": [ { "key": "information-security-policy", "name": "Information security policy", "description": "A board-approved policy set covering information security and the handling of personal data, sized to the scale of the organization and the type of activities it actually carries out, reviewed at least annually and communicated to the workforce. The policy set states the direction the organization is taking on information security - what it commits to, and what it requires of everyone doing work for it - so it sets where the program is going rather than only recording what it already does. One or more named individuals are designated to coordinate the program the policies describe - the person in charge of it, named rather than implied, with the designation recorded in writing, made known to the people who need it and kept current as roles change - so there is someone who answers for the policies being carried out and not only for their being published. How far the policies go, and how far the measures they require go, is judged against four things together: the organization’s size, complexity and capabilities; its technical infrastructure and the security capabilities of its hardware and software; what the measures cost; and how likely the risks they address are and how much damage they would do. A policy may be changed at any time, provided the change is documented and is actually put into effect rather than only written down. Review is triggered by events as well as by the calendar: the policy set is revisited and updated when the requirements the organization is under change, when the threat picture changes, when the technology it depends on changes, and when its mission changes - and it is enforced rather than only issued, with non-compliance handled through the stated route instead of tolerated.", "crosswalks": { "iso-27001": [ "5.2", "A.5.1" ], "soc-2": [ "CC5.3" ], "nist-csf": [ "GV.PO-01", "GV.PO-02" ], "pci-dss": [ "12.1" ], "hipaa": [ "164.316(a)", "164.530(i)(1)" ], "esg-essentials": [ "G.9" ], "gdpr": [ "Art.24(2)" ], "nist-800-53": [ "PL-1" ], "coppa": [ "312.8(a)", "312.8(b)(1)" ], "sox": [ "P12" ], "pipeda": [ "4.1.4", "4.7" ], "fedramp-rev5-class-b": [ "PL-1" ], "fedramp-rev5-class-c": [ "PL-1" ], "fedramp-rev5-class-d": [ "PL-1" ] } }, { "key": "risk-assessment", "name": "Risk assessment & treatment", "description": "A documented process to identify, analyze, evaluate, and treat information security risks on a defined cadence, and again whenever a significant change is proposed or has happened - a new system, a new supplier, a reorganization, a serious incident - so the picture is refreshed by events and not only by the calendar. The process is repeatable: the criteria for accepting risk and for deciding when an assessment is performed are set in advance and applied the same way each time, so repeated assessments produce consistent, comparable and valid results rather than a different answer depending on who ran it. Every risk has a named owner who approves how it will be treated and accepts what is left afterwards. The assessment covers risks and vulnerabilities to the confidentiality, the integrity and the availability of the data the organization holds - all three, not confidentiality alone - and is accurate and thorough enough to be relied on by the decisions taken from it. Treatment brings each risk down to a level that is reasonable and appropriate for this organization, which is the target the process is judged against rather than merely recording that a risk exists. Each assessment and its results are retained as documented information. The process is set down as a documented risk assessment policy with supporting procedures, issued to the roles it binds, owned by a named role, and reviewed and updated on a defined cadence and after an event that changes how the organization assesses risk. The criteria are stated as risk appetite and risk tolerance: how much risk the organization is willing to seek in pursuit of its objectives, and how much variation around that it will tolerate - written down, communicated to the people who take risk decisions, and maintained as the organization and its environment change rather than set once and inherited. The method itself is standardized and communicated: how a risk is calculated, how it is documented, which category it falls into and how it is prioritized against the others, so two people assessing the same thing produce the same rating. What the assessment works from is recorded rather than assumed. The threats to the organization, internal as well as external, are identified and written down. The impacts each could have, and how likely each is, are identified and recorded against them. And the threats, the vulnerabilities, the likelihoods and the impacts are then used together to understand the risk as it stands before any treatment is applied, and to decide which responses are taken first. Which measures the organization then puts in place is part of the same process rather than a decision taken somewhere else afterwards, and four things are weighed together whenever one is chosen: the organization’s own size, complexity and capabilities; its technical infrastructure and the security capabilities of the hardware and software it actually runs; what the measure would cost; and how likely the risk it addresses is, together with how much damage that risk would do. No particular technology is mandated by that judgement, so a measure is defensible because those four were taken into account rather than because it is the one everybody buys. Where a regime marks some of its requirements as ones the organization must simply implement and others as ones it must CONSIDER, the second kind is not read as optional: each is assessed against this environment for whether it is a reasonable and appropriate safeguard, judged by what it would actually contribute to protecting the data; it is implemented where that assessment says so; and where it is not, the reason it would not be reasonable and appropriate is DOCUMENTED and an equivalent alternative measure is put in place instead wherever an equivalent one is itself reasonable and appropriate. The assessment, the decision and any alternative are recorded together, so a requirement that was considered and set aside is distinguishable from one nobody ever reached.", "crosswalks": { "nist-csf": [ "GV.RM-02", "GV.RM-06", "ID.RA-03", "ID.RA-04", "ID.RA-05" ], "iso-27001": [ "6.1", "8.2" ], "soc-2": [ "CC3.2", "CC3.4" ], "pci-dss": [ "12.3" ], "hipaa": [ "164.306(b)", "164.306(d)", "164.308(a)(1)(ii)(A)", "164.308(a)(1)(ii)(B)" ], "nist-800-171": [ "3.11.1" ], "nist-800-53": [ "RA-1", "RA-3", "RA-7" ], "coppa": [ "312.8(b)(2)" ], "gdpr": [ "Art.32(2)" ], "fedramp-rev5-class-b": [ "RA-1", "RA-3", "RA-7" ], "fedramp-rev5-class-c": [ "RA-1", "RA-3", "RA-7" ], "fedramp-rev5-class-d": [ "RA-1", "RA-3", "RA-7" ] } }, { "key": "access-control-policy", "name": "Access control policy", "description": "Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege; anyone who works with sensitive data, or in a place from which it can be reached, is individually authorized for that work or supervised while doing it; and a documented emergency route exists to obtain the data when the normal access path is unavailable, with every use of that route recorded and reviewed afterwards. The rules also settle the opposite question: which actions, if any, a person may take on a system without identifying or authenticating themselves at all. Those actions are identified rather than left as whatever the system happens to permit, they are limited to what the organization’s business actually requires, and each one is documented in the system’s security plan together with the reasoning that justifies it, so an unauthenticated path is a decision somebody made and can be asked about. The rules are enforced by access control lists set on the data itself, not only by what an application chooses to show: permissions on local and remote file systems, on databases and inside applications are configured to the holder’s need to know, so information a role has no business reading is unreachable rather than merely unadvertised. What an authorized user may DO is limited on the same terms as what they may read: the types of transaction and function each role is permitted to execute are decided in advance and enforced by the system, so holding access to an application does not carry the right to run every operation inside it, and an action outside the permitted set is refused rather than merely unadvertised in the interface. Enforcement is centralized wherever the systems support it - access decisions for enterprise assets are made by a single directory service or single sign-on provider rather than by each system keeping its own list - and the systems that make those decisions are themselves known: an inventory of the organization’s authentication and authorization systems is maintained, including those run by a service provider on its behalf, and reviewed on a defined cadence. Who needs the data is settled in advance and written down rather than discovered one request at a time: the people, and the classes of people, in the workforce who need access to sensitive personal data to carry out their duties are IDENTIFIED by name or by role, and for each of them the CATEGORIES of that data they actually need and any CONDITIONS attaching to the access are identified alongside. What is then granted is limited to match what was identified, and the identification is revisited when duties or roles change rather than left as the map somebody drew once. The principle underneath all of it is stated once and runs on every axis: what is used, what is disclosed and what is REQUESTED from another organization is limited, by reasonable effort, to the minimum needed to accomplish the purpose it is being used, disclosed or requested for. The regimes that impose that rule also name where it does not run, and those cases are decided against the exemption rather than squeezed through the rule - a treating clinician asking for what they need in order to treat someone, data given to the person it is about, a disclosure the individual has specifically authorized, a disclosure to the regulator investigating the organization’s compliance, a disclosure the law requires, and whatever the organization has to use in order to comply with the rules themselves.", "crosswalks": { "fedramp-rev5-class-c": [ "AC-2(9)", "IA-2(5)", "AC-1", "AC-2", "AC-3", "AC-6", "AC-14" ], "fedramp-rev5-class-d": [ "AC-10", "AC-2(11)", "AC-2(9)", "IA-2(5)", "AC-1", "AC-2", "AC-3", "AC-6", "AC-14" ], "fedramp-20x": [ "KSI-IAM-ELP" ], "iso-27001": [ "A.5.15" ], "soc-2": [ "CC6.1", "CC6.3" ], "nist-csf": [ "PR.AA-05" ], "pci-dss": [ "7.1", "7.2", "7.3" ], "hipaa": [ "164.308(a)(3)(ii)(A)", "164.308(a)(4)(ii)(B)", "164.312(a)(2)(ii)", "164.502(b)", "164.514(d)(2)" ], "nist-800-171": [ "3.1.1", "3.1.2", "3.1.5" ], "cis-controls": [ "3.3", "6.6", "6.7", "6.8" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "AC-1", "AC-2", "AC-3", "AC-6", "AC-14" ], "coppa": [ "312.8(b)(3)" ], "sox": [ "P11" ], "pipeda": [ "4.7.1", "4.7.3" ], "fedramp-rev5-class-b": [ "AC-1", "AC-2", "AC-3", "AC-14" ] } }, { "key": "user-lifecycle", "name": "User provisioning & deprovisioning", "description": "Joiner/mover/leaver process to grant, change, and promptly remove access across systems, in which every person is issued an account of their own carrying a unique name or number, so an action in a log traces back to one named individual rather than to a shared or generic login. Each person’s right of access is recorded when it is established and reviewed on a schedule thereafter, as well as granted and changed - so what someone holds is a documented position that has been looked at again, not the accumulated residue of past requests - and what may be granted follows the organization’s access authorization rules rather than the judgment of whoever processes the request. Identity is managed as a lifecycle in its own right and not only as the access hung off it: an identity is created only after the person or the thing behind it has been verified to a stated standard, is linked to a single accountable human owner, and is disabled and then retired on a defined path rather than deleted where the record has to survive for an audit trail. A shared or generic identity exists only where there is a reason it cannot be individual, and then it is authorized, given an owner who answers for what is done with it, and reviewed. Identities issued to services, applications, devices and automation are registered on the same terms as human ones, with an owner, a purpose and a review date, because an unowned machine identity outlives every person who knew what it was for. Dormant identities are detected and removed rather than waiting for a leaver process that was never triggered. The lifecycle is run by automated mechanisms wherever the systems allow it: accounts are provisioned and deprovisioned from an authoritative source of record, and each act of creating, modifying, enabling, disabling or removing an account generates an audit record automatically rather than depending on the administrator to note it. An account issued for a temporary or emergency purpose carries an expiry from the moment it is created and is disabled or removed automatically when that expiry passes, so a route opened for one situation does not stay open after it. An account is disabled within a defined period when it has expired, when it is no longer associated with any individual, when it is in violation of the organization’s policy, or when it has been inactive beyond a defined period - and where an individual is found to pose a significant risk, within a defined period of that discovery rather than at the next scheduled review. Identifiers are managed as an object in their own right: an identifier is authorized before it is assigned, is selected to a defined convention, is never reused for a different person or entity, and is issued on the same terms whether it names an individual, a group, a role, a service or a device - and where the organization needs to distinguish one class of person from another, such as an employee from a contractor or a vendor, the identifier or its record carries that status rather than leaving it to be inferred. Identity proofing is performed to the assurance level the access warrants: the applicant is resolved to a single unique individual, is required to present identity evidence to whoever registers them, and that evidence is validated and verified by methods the organization has defined rather than accepted on sight, with an address of record confirmed through an out-of-band channel where the assurance level calls for it. All of it is answerable from one INVENTORY OF ACCOUNTS rather than from each system in turn: every account the organization manages is listed - ordinary user, administrator and service alike - with the person or function behind it, the account name, the dates it starts and stops, the department or owner it belongs to and the privilege it carries, and the list is validated against what is actually active on a defined recurring schedule, so an account nobody can account for is found by the review rather than by an incident. Accounts are managed centrally through a directory or identity service wherever a system can be brought into one, because an account that lives only inside an application is the one a leaver process misses. Where a regime requires the identifier itself to carry the STATUS of the person holding it, such as contractor, vendor or foreign national, the account identifier records that status rather than leaving it to a list kept somewhere else, so the status travels with every use of the account.", "crosswalks": { "fedramp-rev5-class-d": [ "IA-12(4)", "PS-4(2)", "AC-2", "AC-2(1)", "AC-2(2)", "AC-2(3)", "AC-2(4)", "AC-2(13)", "IA-4", "IA-4(4)", "IA-12", "IA-12(2)", "IA-12(3)", "IA-12(5)", "PS-4", "PS-5" ], "fedramp-20x": [ "KSI-IAM-AAM", "KSI-IAM-SUS" ], "iso-27001": [ "A.5.16", "A.5.18", "A.8.3" ], "soc-2": [ "CC6.2", "CC6.3" ], "nist-csf": [ "PR.AA-01", "PR.AA-02" ], "pci-dss": [ "8.2" ], "hipaa": [ "164.308(a)(4)(ii)(B)", "164.308(a)(4)(ii)(C)", "164.312(a)(2)(i)" ], "nist-800-171": [ "3.1.1", "3.5.1", "3.5.5", "3.5.6", "3.9.2" ], "cis-controls": [ "5.1", "5.3", "5.5", "5.6", "6.1", "6.2" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "AC-2", "AC-2(1)", "AC-2(2)", "AC-2(3)", "AC-2(4)", "AC-2(13)", "IA-4", "IA-4(4)", "IA-12", "IA-12(2)", "IA-12(3)", "IA-12(5)", "PS-4", "PS-5" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "AC-2", "IA-4", "PS-4", "PS-5" ], "fedramp-rev5-class-c": [ "AC-2", "AC-2(1)", "AC-2(2)", "AC-2(3)", "AC-2(4)", "AC-2(13)", "IA-4", "IA-4(4)", "IA-12", "IA-12(2)", "IA-12(3)", "IA-12(5)", "PS-4", "PS-5" ] } }, { "key": "mfa", "name": "Multi-factor authentication", "description": "Documented procedures verify that a person or system seeking access to sensitive data is the one it claims to be, on every path by which that data can be reached - and multi-factor authentication is the enforced mechanism for remote access, administrative access, and access to sensitive systems and data. The multi-factor mechanism itself is configured so it cannot be bypassed, so the factors it uses are genuinely independent of one another - one factor’s success granting no knowledge of and no route around another - and so access is refused unless every factor required has succeeded. The requirement is not confined to the accounts that carry privilege: every account is covered, privileged and non-privileged alike, because an ordinary account is the usual way into a privileged one. The mechanisms chosen are resistant to replay, so an authentication captured on the wire or lifted from a log cannot be presented again to gain access. Authentication is not a single event at the start of a session either: the person is required to authenticate again when the organization’s defined circumstances arise - a change of role or of the authenticators themselves, an escalation to privilege, a session that has run beyond its defined life, or a request to perform an action the organization has designated as requiring fresh proof. Where a regime requires the factors to be PHISHING-RESISTANT rather than merely replay-resistant, the organization uses factors that resist verifier impersonation, such as a hardware security key or a platform authenticator bound to the origin by public-key cryptography. A one-time code or a push approval does not count toward that requirement: both resist replay and neither survives an attacker relaying the exchange in real time.", "crosswalks": { "fedramp-rev5-class-c": [ "IA-2(6)", "IA-2", "IA-2(1)", "IA-2(2)", "IA-2(8)", "IA-11" ], "fedramp-rev5-class-d": [ "IA-2(6)", "IA-2", "IA-2(1)", "IA-2(2)", "IA-2(8)", "IA-11" ], "fedramp-20x": [ "KSI-IAM-APM" ], "iso-27001": [ "A.8.5" ], "soc-2": [ "CC6.1" ], "nist-csf": [ "PR.AA-03" ], "pci-dss": [ "8.4", "8.5" ], "hipaa": [ "164.312(d)" ], "nist-800-171": [ "3.5.2", "3.5.3", "3.5.4" ], "cis-controls": [ "6.3", "6.4", "6.5" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "IA-2", "IA-2(1)", "IA-2(2)", "IA-2(8)", "IA-11" ], "coppa": [ "312.8(b)(3)" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "IA-2", "IA-2(1)", "IA-2(2)", "IA-2(8)", "IA-11" ] } }, { "key": "credential-management", "name": "Password & credential management", "description": "Rules for the authentication credentials themselves: passwords are unique per account and meet a defined strength standard, a new or changed password is screened against a list of commonly used, expected and compromised passwords and refused if it appears there, a credential issued for first use must be replaced immediately, reuse of previous passwords is refused, changes follow a defined procedure, repeated failed authentication attempts lock the account for a defined period, and passwords, keys and other authentication secrets are stored and transmitted only in protected form. The rules are a documented policy with supporting procedures covering identification and authentication as a whole - who and what must be identified, to what assurance, and by which mechanisms - issued to the people and roles it applies to, owned by a named role, and reviewed and updated on a defined cadence and after a change that affects it. Repeated failure is handled to a stated rule rather than to a default: a limit is set on consecutive invalid authentication attempts within a defined time window, and when that limit is exceeded the system responds automatically in a way the organization has chosen and configured - locking the account for a defined period, delaying further attempts by a defined algorithm, or notifying a defined role - rather than continuing to accept attempts. What is displayed back to the person authenticating is obscured while they do it, so a credential cannot be read off the screen or recovered from the feedback the system gives. The protection an authenticator receives is proportionate to the sensitivity of what its use unlocks, so a credential granting access to the most sensitive information is stored, transmitted, issued and revoked under stronger handling than one that opens a low-impact system. Where a regime the organization is subject to sets an identity, authenticator or federation assurance LEVEL rather than leaving authenticator strength to judgement, the organization meets the level that regime names, at the grade it names for the particular tier of assurance the organization has committed to, since one regime can set a different level for each tier. Authentication assertions that pass through a third party, such as the browser, are encrypted in transit through it rather than only over the connection.", "crosswalks": { "fedramp-rev5-class-d": [ "IA-5(13)", "IA-5(8)", "AC-7", "IA-1", "IA-5", "IA-5(1)", "IA-5(6)", "IA-6" ], "fedramp-20x": [ "KSI-IAM-APM", "KSI-IAM-SNU", "KSI-SVC-ASM" ], "iso-27001": [ "A.5.17" ], "pci-dss": [ "8.1", "8.3" ], "hipaa": [ "164.308(a)(5)(ii)(D)" ], "cis-controls": [ "5.2" ], "nist-800-171": [ "3.1.8", "3.5.7", "3.5.8", "3.5.9", "3.5.10", "3.5.11" ], "nist-800-53": [ "AC-7", "IA-1", "IA-5", "IA-5(1)", "IA-5(6)", "IA-6" ], "fedramp-rev5-class-b": [ "AC-7", "IA-1", "IA-5", "IA-5(1)", "IA-6" ], "fedramp-rev5-class-c": [ "AC-7", "IA-1", "IA-5", "IA-5(1)", "IA-5(6)", "IA-6" ] } }, { "key": "encryption", "name": "Encryption in transit & at rest", "description": "Strong cryptography protects sensitive data in transit over public networks and at rest in storage. The mechanisms are chosen to do two things and are judged against both: prevent unauthorized disclosure of the information, and prevent or detect unauthorized change to it - in transit, so a message altered between sender and receiver is caught rather than delivered, and at rest, so a stored record cannot be modified undetectably by somebody with access to the storage but not to the key. Which information is protected at rest, and on which system components, is decided and recorded rather than left to whatever the platform encrypts by default. The scope named explicitly reaches the end-user device as well as the server: data held on laptops, desktops and other end-user devices that carry sensitive information is encrypted at the device or volume level, so a device that leaves the building is an object somebody lost rather than a disclosure. And data in transit is encrypted wherever it is sensitive, not only where it crosses a public network - a session between two internal systems is protected on the same terms when what it carries warrants it. Where a law, a regulation or a contract requires the cryptography to be VALIDATED rather than merely strong, the organization uses a cryptographic module that carries the validation that instrument names, and it confirms that validation against the specific module, version and operating mode actually deployed rather than inferring it from the product’s name - because a validated module run outside the configuration it was validated in is not a validated module, and the certificate that proves the point is held as evidence rather than assumed to exist.", "crosswalks": { "fedramp-rules-2026": [ "CMU-CSO-CAT", "CMU-CSO-UVM" ], "fedramp-20x": [ "KSI-SVC-SIN", "KSI-SVC-VCM", "KSI-SVC-VRI" ], "iso-27001": [ "A.8.24" ], "soc-2": [ "CC6.7" ], "nist-csf": [ "PR.DS-01", "PR.DS-02" ], "pci-dss": [ "3.5", "4.1", "4.2" ], "hipaa": [ "164.312(a)(2)(iv)", "164.312(e)(2)(ii)" ], "nist-800-171": [ "3.13.8", "3.13.11", "3.13.16" ], "cis-controls": [ "3.6", "3.10", "3.11" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "SC-8", "SC-8(1)", "SC-13", "SC-28", "SC-28(1)" ], "coppa": [ "312.8(b)(3)" ], "sox": [ "P11" ], "pipeda": [ "4.7", "4.7.1", "4.7.3" ], "fedramp-rev5-class-b": [ "SC-8", "SC-8(1)", "SC-13", "SC-28", "SC-28(1)" ], "fedramp-rev5-class-c": [ "SC-8", "SC-8(1)", "SC-13", "SC-28", "SC-28(1)" ], "fedramp-rev5-class-d": [ "SC-8", "SC-8(1)", "SC-13", "SC-28", "SC-28(1)" ] } }, { "key": "logging-monitoring", "name": "Logging & monitoring", "description": "Security-relevant events - including successful and failed log-in attempts - are logged, protected, retained, and reviewed for anomalies, and the discrepancies that review finds are reported to the people who act on them. The review runs on a defined cadence and covers the records of system activity as a set - the audit logs, the reports of who accessed what, and the record of security incidents - rather than the log stream alone. For those records to be correlated into one sequence of events, the systems producing them agree on the time: every in-scope system synchronizes its clock to a single approved reference source, the source and the tolerance the organization will accept are specified rather than left to defaults, and timestamps are recorded in an unambiguous form so a reader does not have to infer a time zone. Synchronization is monitored in its own right - a system that drifts beyond tolerance or loses its source raises an alert, because a clock that is wrong makes an investigation reach the wrong conclusion rather than no conclusion - and where equipment cannot be synchronized, its offset is known and recorded so its records can still be placed. Timestamps are generated from the system’s own clock, expressed in Coordinated Universal Time or a recorded offset from it, and cut to a granularity the organization has stated rather than to whatever the platform defaults to. All of this rests on a documented audit and accountability policy with supporting procedures, aligned with the laws and obligations that apply to the organization, issued to the roles it binds, owned by a named role, and reviewed on a defined cadence. WHAT A RECORD CONTAINS is specified rather than accepted: every audit record establishes what type of event occurred, when it occurred, where it occurred, the source it came from, the outcome - success or failure - and the identity of any individual, subject or object associated with it, plus whatever further fields the organization has decided it needs to reconstruct an event afterwards. Because every person holds an account of their own, the identity a record carries resolves to one named individual rather than to a shared or generic login, so an action can be traced to whoever actually took it and that person can be held accountable for it - which is the whole reason the identity field is mandatory rather than useful. WHICH EVENTS ARE LOGGED is decided and then kept under review rather than configured once: the set of event types selected for logging is agreed with the roles who investigate, is reviewed on a defined cadence and again after an incident that showed the set was wrong, and is updated as a result - so the log answers the questions being asked now instead of the ones somebody anticipated at build. Storage is sized for that: enough capacity is allocated to hold the volume produced for the retention period the organization has set, and records are retained for that period specifically so an investigation after the fact is possible and so regulatory and internal obligations are met, rather than for as long as the disk happens to last. When the logging process itself fails - the pipeline stops, the store fills, a source goes silent - a defined role is alerted within a defined time and the organization takes the response it decided on in advance, because a logging failure is the one failure the logs cannot tell you about. REVIEW AND ANALYSIS are supported by machinery rather than by reading. Automated mechanisms integrate the review, analysis and reporting of audit records into a single process, and records drawn from separate repositories are correlated so the organization sees one organization-wide picture of activity instead of several partial ones. A reduction and reporting capability supports on-demand review, analysis and reporting and the investigation of an incident, and it does so without altering the original records or their ordering; it lets an analyst filter, sort and search records by the criteria the organization has defined, so events of interest surface in time to matter. THE RECORDS THEMSELVES ARE PROTECTED as an asset. Audit information and the logging tools that produce it are protected from unauthorized access, modification and deletion, a defined role is alerted when evidence of tampering is detected, and the ability to manage the logging function - what is collected, what is retained, what is deleted - is restricted to a named subset of privileged users rather than being available to every administrator whose activity it records. MONITORING runs on top of the record. The organization monitors its systems to detect attack and indicators of potential attack, unauthorized local, network and remote connections, and use that is outside what it has authorized; it identifies that use against defined criteria for what unusual looks like. Inbound and outbound communications traffic is watched for those conditions specifically, because exfiltration and command traffic look ordinary unless somebody has said what ordinary is. Automated tools and mechanisms support analysis close to real time rather than at the next review, and when the system produces an indication of compromise or potential compromise a defined role is alerted. What monitoring finds is reported to the people who act on it, at the frequency the organization has set. WHICH SOURCES ARE COLLECTED is decided rather than left to whatever a platform emits by default. Access to information the organization has classified as sensitive is logged, including modification and disposal and not only reading. DNS queries, URL requests and command-line activity are collected where the asset supports it, because those three are what an investigation reconstructs an intrusion from, and network traffic flow records are collected from the network devices so that movement between systems can be reviewed and alerted on. Logs from the service providers the organization depends on are collected too, so authentication, user-management and data-lifecycle events that happen outside its own estate sit inside the same record. Collection and retention are centralized so far as the estate allows, into a platform that correlates sources rather than storing them side by side, and security event alerting is centralized on top of it so that a pattern spanning two sources raises one alert to one place. The alerting thresholds are tuned on a defined cadence rather than set once, because an alert stream nobody can read is the same as no alerting at all. Time synchronization uses more than one source: at least two reference sources are configured wherever an asset supports it, so losing one does not silently leave the estate drifting. WHAT IS WATCHED includes people as well as machines: the activity of personnel and their use of the organization’s technology are monitored against what has been authorized for them and against what the organization has told them is monitored, so misuse and a compromised account surface from the same record. Analysis goes past the alert to the activity behind it - what else the same account, host or address did before and after, and whether the separate events form one sequence - so a potentially adverse event is understood rather than merely counted. And each such event is scoped before it is handed on: the estimated impact and the reach of it - which systems, which data, which accounts, over what period - is established from the correlated record and carried into the incident assessment rather than left for the responder to rebuild.", "crosswalks": { "fedramp-rev5-class-c": [ "AC-2(12)", "SC-45", "SC-45(1)", "SI-4(1)", "SI-4(16)", "AU-1", "AU-2", "AU-3", "AU-3(1)", "AU-4", "AU-5", "AU-6", "AU-6(1)", "AU-6(3)", "AU-7", "AU-7(1)", "AU-8", "AU-9", "AU-9(4)", "AU-11", "AU-12", "SI-4", "SI-4(2)", "SI-4(4)", "SI-4(5)" ], "fedramp-rev5-class-d": [ "AC-2(12)", "AU-10", "AU-12(1)", "AU-12(3)", "AU-5(1)", "AU-5(2)", "AU-6(4)", "AU-6(5)", "AU-6(6)", "AU-6(7)", "AU-9(2)", "AU-9(3)", "SC-45", "SC-45(1)", "SI-4(1)", "SI-4(10)", "SI-4(11)", "SI-4(12)", "SI-4(16)", "SI-4(19)", "AU-1", "AU-2", "AU-3", "AU-3(1)", "AU-4", "AU-5", "AU-6", "AU-6(1)", "AU-6(3)", "AU-7", "AU-7(1)", "AU-8", "AU-9", "AU-9(4)", "AU-11", "AU-12", "SI-4", "SI-4(2)", "SI-4(4)", "SI-4(5)" ], "fedramp-20x": [ "KSI-CMT-LMC", "KSI-MLA-ALA", "KSI-MLA-LET", "KSI-MLA-OSM", "KSI-MLA-RVL" ], "iso-27001": [ "A.8.15", "A.8.16", "A.8.17" ], "soc-2": [ "CC7.2" ], "nist-csf": [ "DE.CM-09", "PR.PS-04", "DE.CM-03", "DE.AE-02", "DE.AE-03", "DE.AE-04" ], "pci-dss": [ "10.1", "10.2", "10.3", "10.4", "10.5", "10.6", "10.7" ], "hipaa": [ "164.308(a)(1)(ii)(D)", "164.308(a)(5)(ii)(C)", "164.312(b)" ], "nist-800-171": [ "3.3.1", "3.3.2", "3.3.3", "3.3.4", "3.3.5", "3.3.6", "3.3.7", "3.3.8", "3.3.9", "3.14.6", "3.14.7" ], "cis-controls": [ "3.14", "8.1", "8.2", "8.3", "8.4", "8.5", "8.6", "8.7", "8.8", "8.9", "8.10", "8.11", "8.12", "13.1", "13.6", "13.11" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "AU-1", "AU-2", "AU-3", "AU-3(1)", "AU-4", "AU-5", "AU-6", "AU-6(1)", "AU-6(3)", "AU-7", "AU-7(1)", "AU-8", "AU-9", "AU-9(4)", "AU-11", "AU-12", "SI-4", "SI-4(2)", "SI-4(4)", "SI-4(5)" ], "coppa": [ "312.8(b)(3)" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "AU-1", "AU-2", "AU-3", "AU-4", "AU-5", "AU-6", "AU-8", "AU-9", "AU-11", "AU-12", "SI-4" ] } }, { "key": "vulnerability-management", "name": "Vulnerability management", "description": "Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications, fed by current information about threats and weaknesses collected from outside the organization as well as from its own scans - vendor and industry security advisories for the software actually in use, and the threat feeds, bulletins and sector reporting that describe how systems like these are being attacked now - which is gathered continuously rather than at the next scan, evaluated for whether it applies here, and used to decide what is looked for and what is fixed first. The set of vulnerabilities the scanner actually looks for is updated on a defined cadence and whenever new ones are identified and reported, so a scan reflects what is known today rather than what the tool shipped with. Scans that need to see inside a system are given the privileged access to do so, granted deliberately to the scanning activity for the components that require it rather than left to run blind and report clean. Whether a fix is actually present is confirmed by automated mechanisms that report, per component, which security-relevant software and firmware updates are installed - so remediation is evidenced by the estate rather than by a closed ticket. The organization also runs a PUBLIC intake: a reporting channel that anybody outside the organization can find and use to report a vulnerability they have discovered in its systems or products, with a stated scope, a stated way to report, an acknowledgment, and a route into the same triage and remediation process everything else uses. All of this rests on a documented system and information integrity policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. The scanning and the fixing are each defined rather than assumed. Internal assets are scanned automatically on a defined cadence, both with credentials and without, because the two find different things - one shows what is installed, the other shows what somebody with no account can see. Externally exposed assets are scanned on their own cadence, which is at least as frequent, because they are reachable by everyone. Patching is automated for operating systems and, on the same terms and cadence, for the applications running on them, so an application left to be updated by whoever notices is not the gap. Remediation runs to a documented, risk-based strategy - what is fixed first, within what period, and who may approve an exception - reviewed on a defined cadence rather than written once. The public intake is governed by a written vulnerability handling policy that names how to report, who is responsible for handling a report, and the steps from intake through assignment and remediation to remediation testing, with reports tracked in a system that records a severity rating and the timing of identification, analysis and remediation, so how long the organization takes is a measured number rather than an impression.", "crosswalks": { "fedramp-rules-2026": [ "VDR-CSO-ADT", "VDR-CSO-AKE", "VDR-CSO-DET", "VDR-CSO-FAV", "VDR-CSO-MSP", "VDR-CSO-RES", "VDR-TFR-KEV", "VDR-TFR-MVF", "VDR-TFR-MVX", "VDR-TFR-NMV", "VDR-TFR-PCD", "VDR-TFR-PDD", "VDR-TFR-PSD", "VDR-TFR-PVR", "VDR-TFR-RMN", "VER-EVA-AIA", "VER-EVA-EFA", "VER-EVA-EFP", "VER-EVA-EIR", "VER-EVA-ELX", "VER-EVA-EPA", "VER-EVA-GRV", "VER-RPT-AVI", "VER-RPT-HLO", "VER-RPT-PER", "VER-RPT-VDT", "VER-TFR-EVU", "VER-TFR-MHR", "VER-TFR-MRH" ], "fedramp-rev5-class-c": [ "RA-5(3)", "SI-2(3)", "RA-5", "RA-5(2)", "RA-5(5)", "RA-5(11)", "SI-1", "SI-2", "SI-2(2)" ], "fedramp-rev5-class-d": [ "RA-5(3)", "RA-5(4)", "RA-5(8)", "SI-2(3)", "RA-5", "RA-5(2)", "RA-5(5)", "RA-5(11)", "SI-1", "SI-2", "SI-2(2)" ], "fedramp-20x": [ "KSI-PIY-RVD", "KSI-SCR-MON" ], "iso-27001": [ "A.5.7", "A.8.8" ], "soc-2": [ "CC7.1" ], "nist-csf": [ "ID.RA-01", "ID.RA-08" ], "pci-dss": [ "6.3", "11.1", "11.3" ], "nist-800-171": [ "3.11.2", "3.11.3", "3.14.1" ], "cis-controls": [ "7.1", "7.2", "7.3", "7.4", "7.5", "7.6", "7.7", "16.2" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "RA-5", "RA-5(2)", "RA-5(5)", "RA-5(11)", "SI-1", "SI-2", "SI-2(2)" ], "coppa": [ "312.8(b)(4)" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "RA-5", "RA-5(2)", "RA-5(11)", "SI-1", "SI-2" ] } }, { "key": "penetration-testing", "name": "Penetration testing program", "description": "A defined penetration-testing program - who tests, what is in scope, on what schedule and to what rules of engagement - under which testers attempt real attacks against externally exposed systems and, separately, from inside the network; findings are prioritized by risk and remediated; and the fix is retested to confirm the security measure now works as intended. The scope reaches the APPLICATION as well as the network: applications the organization has judged critical are penetration tested by a person manipulating them as both an authenticated and an unauthenticated user, because the flaws that matter most in an application are business-logic flaws a scanner and an automated test cannot express. The testing is a source of improvement as well as of findings, and it reaches EXERCISES as well as tests: tabletop and live exercises run alongside the technical testing, and where a supplier or other third party is part of the system under test it takes part rather than being assumed to hold up its end. What each test and exercise shows about the controls, the plans and the people is captured as an improvement with an owner and a date, not only as a vulnerability to be closed.", "crosswalks": { "fedramp-rev5-class-b": [ "CA-8" ], "fedramp-rev5-class-c": [ "CA-8", "CA-8(1)", "CA-8(2)" ], "fedramp-rev5-class-d": [ "CA-8", "CA-8(1)", "CA-8(2)" ], "nist-csf": [ "ID.IM-02" ], "pci-dss": [ "11.4" ], "cis-controls": [ "16.13", "18.1", "18.2", "18.3", "18.4", "18.5" ] } }, { "key": "malware-protection", "name": "Malware protection", "description": "Anti-malware controls prevent, detect, and respond to malicious software on endpoints and servers, and detections are reported to the people who act on them. The mechanism is kept live rather than merely installed: signatures, definitions and detection engines update automatically as the vendor issues them rather than on someone remembering to apply them, what it detects and what it does about it is logged, and it runs where an ordinary user cannot switch it off, uninstall it or exclude their way around it - only a documented, authorized change may disable it, and then for a stated period. UNSOLICITED MESSAGES are handled by the same program rather than treated as a nuisance: spam protection is deployed at the system entry and exit points - the mail gateway, the web gateway, the remote access path and the mobile devices - to detect unsolicited messages and to act on them, and its mechanisms and signatures update automatically at a defined frequency and as new releases are issued, on the same terms as the anti-malware engine, because a spam filter running last quarter’s rules is where the phishing message that starts an incident gets through. The estate is managed from one place rather than device by device: policy, exclusions, engine versions and detections are administered centrally, so what is deployed and what it found are answerable without visiting a machine. Detection is not signature-only - behavior-based detection runs alongside the signature engine to catch what no definition describes yet - and it extends into host-based intrusion detection and prevention on enterprise assets: an agent that watches for and blocks malicious ACTIVITY on the host rather than only files it recognizes as malware. The operating system’s own anti-exploitation features are enabled wherever the platform provides them, because a protection already built into the system and left switched off is the cheapest gap in the estate. REMOVABLE MEDIA are handled as an entry route: automatic execution on insertion is disabled, and the media are scanned automatically when they are connected rather than at the holder’s discretion. The EMAIL PATH carries anti-malware in its own right - the mail server or gateway scans attachments and detonates what it cannot judge by inspection alone - and file types the organization has no business need to receive are blocked at that gateway before anybody has to make a decision about them. SCANNING RUNS ON TWO SCHEDULES rather than one, because they catch different things. The estate is scanned in full on a defined periodic cadence, so a file that was clean when it landed is re-examined against what is known today. And files arriving from outside the organization are scanned in real time as they are downloaded, opened or executed - at the moment of use rather than at the next sweep - so nothing waits for a scheduled scan to be caught. Where the organization sends email on another party's behalf and a regime requires that mail to be authenticated, the sending domain publishes a DMARC policy set to reject, names the aggregate report address that regime specifies among its recipients, and the sending domains are recorded so the ones covered are known.", "crosswalks": { "iso-27001": [ "A.8.7" ], "soc-2": [ "CC6.8" ], "pci-dss": [ "5.1", "5.2", "5.3" ], "hipaa": [ "164.308(a)(5)(ii)(B)" ], "nist-800-171": [ "3.14.2", "3.14.4", "3.14.5" ], "cis-controls": [ "9.6", "9.7", "10.1", "10.2", "10.3", "10.4", "10.5", "10.6", "10.7", "13.2", "13.7" ], "nist-800-53": [ "SI-3", "SI-8", "SI-8(2)" ], "fedramp-rev5-class-b": [ "SI-3" ], "fedramp-rev5-class-c": [ "SI-3", "SI-8", "SI-8(2)" ], "fedramp-rev5-class-d": [ "SI-3", "SI-8", "SI-8(2)" ] } }, { "key": "backups", "name": "Backups", "description": "Regular, tested backups of critical data and systems with defined retention, each one a RETRIEVABLE EXACT COPY of the data it protects - complete and restorable, not a partial or lossy snapshot - including a copy taken before equipment holding that data is moved. Backup information is tested on a defined cadence to verify that the media are still reliable and the information still has its integrity - a restore actually performed, not a job that reported success - and it is protected by cryptographic mechanisms so a copy obtained by somebody who should not have it discloses nothing and cannot be altered undetected. Copies are held somewhere other than where the original lives: an alternate storage site is established, with the agreements needed to store backups there and to retrieve them when they are wanted, carrying security controls equivalent to those at the primary site rather than weaker ones because it is only a copy. The alternate site is chosen far enough from the primary that the same fire, flood, outage or regional event is unlikely to take both, and the organization identifies in advance the problems that would make the site hard to reach during a wide-area disruption - roads, transport, staff availability, network dependency - and states explicit mitigation actions for each rather than discovering them on the day. The recovery itself is a documented process and not only a schedule: it states which assets are in scope for recovery, the order in which they are brought back, and how the backup data is protected while it waits, and it is reviewed and updated on a defined cadence and whenever a change to the organization would alter it. Recovery data carries protection EQUIVALENT to the data it copies rather than weaker protection because it is a copy. And at least one instance of it is ISOLATED - held offline, off-site, or in a separately controlled service, out of reach of the credentials and the network paths that operate the live environment - so an event that reaches production does not also reach the copy that would undo it. Verification is performed at the point of USE as well as on the cadence: before a backup or any other restoration asset is relied on to bring a system back, its integrity is checked against the value recorded when it was taken and the check is logged - so a restoration does not carry corrupted or tampered data into a system that has just been cleaned.", "crosswalks": { "fedramp-rev5-class-d": [ "CP-6(2)", "CP-9(2)", "CP-9(3)", "CP-9(5)", "CP-6", "CP-6(1)", "CP-6(3)", "CP-9", "CP-9(1)", "CP-9(8)" ], "fedramp-20x": [ "KSI-RPL-ABO", "KSI-RPL-TRC" ], "iso-27001": [ "A.8.13" ], "soc-2": [ "A1.2" ], "nist-csf": [ "PR.DS-11", "RC.RP-03" ], "hipaa": [ "164.308(a)(7)(ii)(A)", "164.310(d)(2)(iv)" ], "cis-controls": [ "11.1", "11.2", "11.3", "11.4", "11.5" ], "gdpr": [ "Art.32(1)" ], "nist-800-171": [ "3.8.9" ], "nist-800-53": [ "CP-6", "CP-6(1)", "CP-6(3)", "CP-9", "CP-9(1)", "CP-9(8)" ], "sox": [ "P11" ], "pipeda": [ "4.7.1" ], "fedramp-rev5-class-b": [ "CP-9" ], "fedramp-rev5-class-c": [ "CP-6", "CP-6(1)", "CP-6(3)", "CP-9", "CP-9(1)", "CP-9(8)" ] } }, { "key": "business-continuity", "name": "Business continuity & disaster recovery", "description": "BC/DR plans with defined RTO/RPO, tested periodically AND REVISED on what the testing finds and on what has changed since, to restore service after disruption - including how the critical processes that protect sensitive data keep running while the organization is operating in emergency mode, and an assessment of how critical each application and data set is, which is what sets those recovery targets and the order in which things come back. The disruptions the organization could actually face are identified and a response chosen for each, rather than one plan written against one scenario, and the loss that would still remain after those responses is quantified and put to a deliberate decision - accepted, reduced further, or transferred, including by insurance - so exposure to a disruption is something somebody chose rather than something nobody priced. The level of information security to be MAINTAINED while the organization is disrupted is decided in advance rather than allowed to fall to whatever the emergency leaves standing: for each control that cannot run in the degraded state, a compensating measure is defined for the period, and where none is available the exposure is accepted deliberately and for a stated maximum duration. The alternate site, the standby service and the emergency working arrangements carry protection equivalent to normal operations - the same access rules, the same logging, the same handling of sensitive information - and the security of those arrangements is exercised in the same tests rather than assumed to have been inherited. Restoring normal operation includes restoring the controls that were relaxed, and confirming that they are back on. The program rests on a documented contingency planning policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. The plan is not written alone: it is developed in coordination with the organizational elements responsible for the related plans - incident response, crisis management, physical security, occupant emergency, supply chain - so the plans agree about who does what rather than each assuming the others, and the testing is coordinated with those same elements for the same reason. What has to come back is named rather than implied: the essential mission and business functions are identified, the critical system assets and components that support them are identified through a deliberate criticality analysis performed at defined points in the system’s life rather than once at the start, and the plan states the time within which each essential function will be resumed after the plan is activated. Testing runs on a defined cadence using methods chosen to establish the plan’s effectiveness and the organization’s readiness to execute it, and the results are reviewed and corrective action taken. People are trained for the role the plan gives them: within a defined period of being assigned it, again when the system or the plan changes materially, and on a defined cadence thereafter, with the training content revised for what the exercises and the incidents showed. Where a system is transaction-based, recovery includes the transactions themselves - the mechanisms that let in-flight work be rolled back or replayed to a consistent point, so recovery does not mean a service that is up over data that is half-written. The criticality analysis names the objectives, capabilities and services that parties OUTSIDE the organization depend on or expect from it - customers, regulators, and the organizations it is itself a supplier to - and what the organization commits to restoring, and how quickly, is communicated to them rather than held internally. Recovery is entered deliberately rather than drifted into: the criteria for initiating it are set in advance and applied to the incident in front of the responders, and the recovery actions are then selected, scoped, prioritized and performed against the plan instead of improvised in the order things are noticed. What normal looks like afterwards is a decision too - the essential mission functions and the risk picture the incident has just changed are both considered when the post-incident operating norms are set, so the organization does not return to a posture the incident has already disproved. The end of recovery is declared against stated criteria by the role authorized to declare it, and the recovery documentation is completed at that point rather than left open behind a service that is back up.", "crosswalks": { "fedramp-rev5-class-d": [ "CP-10(4)", "CP-2(5)", "CP-3(1)", "CP-4(2)", "CP-1", "CP-2", "CP-2(1)", "CP-2(3)", "CP-2(8)", "CP-3", "CP-4", "CP-4(1)", "CP-10", "CP-10(2)", "RA-9" ], "fedramp-20x": [ "KSI-RPL-ARP", "KSI-RPL-RRO", "KSI-RPL-TRC" ], "iso-27001": [ "A.5.29", "A.5.30" ], "soc-2": [ "A1.2", "A1.3", "CC9.1" ], "nist-csf": [ "RC.RP-01", "GV.OC-04", "RS.MA-05", "RC.RP-02", "RC.RP-04", "RC.RP-06" ], "hipaa": [ "164.308(a)(7)(ii)(B)", "164.308(a)(7)(ii)(C)", "164.308(a)(7)(ii)(D)", "164.308(a)(7)(ii)(E)" ], "gdpr": [ "Art.32(1)" ], "nist-800-53": [ "CP-1", "CP-2", "CP-2(1)", "CP-2(3)", "CP-2(8)", "CP-3", "CP-4", "CP-4(1)", "CP-10", "CP-10(2)", "RA-9" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "CP-1", "CP-2", "CP-3", "CP-4", "CP-10" ], "fedramp-rev5-class-c": [ "CP-1", "CP-2", "CP-2(1)", "CP-2(3)", "CP-2(8)", "CP-3", "CP-4", "CP-4(1)", "CP-10", "CP-10(2)", "RA-9" ] } }, { "key": "incident-response", "name": "Incident response", "description": "A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents, and to mitigate - so far as is practicable - the harmful effect of a use or disclosure of personal data the organization knows breached its own policies or the law. Each incident is recorded together with its outcome - what happened, what was done about it and how it ended - as a record of that incident, which is a different artifact from the plan being documented. The mitigation duty runs to violations by the organization itself AND to violations by the processors, vendors and other parties handling that data on its behalf: the plan reaches an incident somebody else caused with the organization’s data, so learning of one triggers the same containment and remediation as an incident inside its own walls rather than a request that the other party deal with it. Where an incident carries a duty to tell someone outside the organization, the plan discharges it on the clock the applicable law sets - and, where the organization has itself committed to a timeframe for telling people, on that commitment too, whether or not a statute stands behind it - rather than whenever the investigation happens to conclude: whether an incident is notifiable is decided against written criteria rather than argued after the fact, the regulator or supervisory authority is notified inside the deadline that regime states and inside any shorter or additional timeframe the organization has committed to, the people whose data is affected are told where the risk to them warrants it and, independently of that threshold, wherever the organization’s own privacy commitments say they will be told - so individual notification is never conditioned solely on a statutory risk test - and any other party that law or those commitments require to be notified is told on the same terms, and where a deadline is missed the notification itself explains the delay instead of passing over it. What a notification carries is fixed in advance rather than composed under pressure: to a regulator it describes at least the nature of what happened, including where possible the categories and the approximate number of people affected and of records involved; names a contact point - the data protection officer where there is one, otherwise whoever can answer - from whom more can be obtained; describes the likely consequences; and describes the measures taken or proposed to address it, including where appropriate the measures that will mitigate its adverse effects. Where all of that cannot honestly be given at once, it is given in phases without further undue delay rather than held back until the picture is complete, and each phase says what is still outstanding. The communication to the people affected describes what happened in clear and plain language and carries the same contact point, likely consequences and measures. Every compromise of personal data is documented whether or not it turned out to be notifiable - the facts of it, its effects, and the remedial action taken - in enough detail that a regulator reviewing the file can verify for itself that the notification decision was the right one. Recovery is part of the plan rather than something that follows it: service and data are restored to a state the organization has established is clean, the restoration is verified before the system is handed back to use, the cause is determined rather than inferred from the symptom, and the weakness the incident exposed is fixed - with the plan itself updated for what the incident showed about it. Between the report and the response sits an assessment step that is a duty of its own: every reported event is assessed against written categorization and prioritization criteria by people competent to apply them, and the decision - whether this event is an incident, and at what severity - is recorded with the reasoning, so two assessors reach the same answer and an event judged not to be an incident is a decision somebody made rather than a report that went quiet. Learning is treated as a duty separate from fixing the incident in front of you: the types, volumes and costs of incidents are quantified and reviewed as a set for what the pattern says, and what is learned is pushed back into the controls, the risk assessment, the awareness material and the assessment criteria themselves rather than staying in the report of the incident that produced it. The plan is a documented incident response policy with supporting procedures, issued to the roles it binds, owned by a named role, and reviewed and updated on a defined cadence. The people the plan assigns roles to are trained for them: within a defined period of taking the role, again when the system or the plan changes in a way that affects it, and on a defined cadence thereafter, with the content revised for what exercises and real incidents have shown. The capability is TESTED rather than assumed - on a defined cadence, using tests the organization has chosen for the purpose, such as a tabletop, a walkthrough, a simulation or a live exercise - and that testing is coordinated with the organizational elements that own the related plans, incident response and contingency planning in particular, so the two do not each assume the other. Handling and reporting are supported by automated mechanisms rather than run by hand at the worst moment: detection, triage, tracking, evidence collection and the routing of a report are automated so far as the organization’s systems allow, and the reports that must go outside are produced and sent by mechanism rather than composed under pressure. The roles the plan assigns are named across the functions an incident actually needs and not security alone - legal, IT, information security, facilities, communications, human resources, the responders and the analysts - and the assignment is reviewed on a defined cadence. So are the CHANNELS: a primary and a secondary mechanism for communicating and reporting during an incident are chosen in advance, on the understanding that the ordinary one may be the thing that is unavailable or compromised, and both are reviewed on the same cadence. The plan reaches the parties outside the organization that an incident actually involves: the suppliers and other third parties whose services, staff or systems would be part of the response are named in it, take part in the planning and the exercises, and are called on during response and recovery on terms agreed in advance rather than negotiated during the event. ESCALATION is a defined step and not a judgment call - the plan states the conditions under which an incident is escalated or elevated, whether by severity, by elapsed time, by the functions it has reached or by the obligations it triggers, who it goes to at each step, and what changes when it gets there. The analysis establishes what actually took place during the incident as well as why it happened, and the incident’s magnitude - how many systems, records and people it reached, and over what period - is estimated as the investigation proceeds and then VALIDATED against the evidence rather than left at the first number anybody said out loud. Notification runs to internal stakeholders as well as external ones, so the functions inside the organization that have to act on an incident are told on the same defined terms as the parties outside it. And containment is followed by ERADICATION as a separate act: the malicious code, the unauthorized access and the persistence left behind are removed and their removal is confirmed, so a contained incident is not mistaken for a finished one.", "crosswalks": { "fedramp-rules-2026": [ "IEC-CSO-DPR", "IEC-CSO-EFI", "IEC-CSO-EFR", "VER-TFR-IRI", "VER-TFR-NRI" ], "fedramp-rev5-class-c": [ "IR-9", "IR-9(2)", "IR-9(3)", "IR-9(4)", "IR-1", "IR-2", "IR-3", "IR-3(2)", "IR-4", "IR-4(1)", "IR-5", "IR-6", "IR-6(1)", "IR-8" ], "fedramp-rev5-class-d": [ "IR-2(1)", "IR-2(2)", "IR-4(11)", "IR-4(2)", "IR-4(4)", "IR-4(6)", "IR-5(1)", "IR-9", "IR-9(2)", "IR-9(3)", "IR-9(4)", "IR-1", "IR-2", "IR-3", "IR-3(2)", "IR-4", "IR-4(1)", "IR-5", "IR-6", "IR-6(1)", "IR-8" ], "fedramp-20x": [ "KSI-INR-AAR", "KSI-INR-RIR", "KSI-INR-RPI" ], "iso-27001": [ "A.5.24", "A.5.25", "A.5.26", "A.5.27" ], "soc-2": [ "CC7.3", "CC7.4", "CC7.5", "P6.6" ], "nist-csf": [ "RS.MA-01", "GV.SC-08", "ID.IM-04", "DE.AE-08", "RS.MA-03", "RS.MA-04", "RS.AN-03", "RS.AN-08", "RS.CO-02", "RS.MI-01", "RS.MI-02" ], "pci-dss": [ "12.10" ], "hipaa": [ "164.308(a)(6)(ii)", "164.530(f)" ], "nist-800-171": [ "3.6.1", "3.6.2", "3.6.3" ], "cis-controls": [ "17.1", "17.4", "17.5", "17.6", "17.7", "17.8", "17.9" ], "gdpr": [ "Art.33(1)", "Art.33(3)", "Art.33(4)", "Art.33(5)", "Art.34(1)", "Art.34(2)" ], "nist-800-53": [ "IR-1", "IR-2", "IR-3", "IR-3(2)", "IR-4", "IR-4(1)", "IR-5", "IR-6", "IR-6(1)", "IR-8" ], "coppa": [ "312.8(a)" ], "sox": [ "P11" ], "pipeda": [ "10.1(1)", "10.1(2)", "10.1(3)", "10.1(4)", "10.1(5)", "10.1(6)", "10.2(1)", "10.2(2)", "10.3(1)", "10.3(2)" ], "fedramp-rev5-class-b": [ "IR-1", "IR-2", "IR-4", "IR-5", "IR-6", "IR-8" ] } }, { "key": "change-management", "name": "Change management", "description": "Changes to systems and software are requested, reviewed, tested, approved, and tracked. Each request is explicitly approved OR DISAPPROVED by a role authorized to decide it, rather than proceeding because nobody objected, and the decision, the reason behind it and the change itself are written to a durable record - so the log shows what was refused as well as what shipped, and a change that went in without a decision is visible as one. A proposed change is analyzed for what it would do to security and privacy BEFORE it is approved, so the decision is taken with that answer in hand rather than reported afterwards; where the change is significant, the analysis is recorded and the roles who own the affected controls see it. Change control is a body rather than a queue: security and privacy representatives are members of the group that approves changes, so the question is asked in the room instead of by exception. A change is tested, validated and documented before it is finalized and moved into the running system, in an environment that resembles the one it is going to. After it lands, the controls it touched are verified to be implemented correctly, still operating as intended, and still producing the result the organization’s security and privacy requirements call for - verified, not assumed from the fact that the deployment succeeded. Who may make a change at all is restricted: the physical and logical access needed to alter a system is defined, documented, approved and enforced, and it is a narrower set than the people who may use the system. EXCEPTIONS are managed on the same terms as changes: a departure from a standard, a baseline or a policy is requested, assessed for the risk it creates, approved by a role authorized to accept that risk, recorded with a scope and an expiry, and tracked to closure or to a deliberate renewal - so an exception is a change somebody decided rather than a state nobody revisits.", "crosswalks": { "fedramp-rules-2026": [ "VDR-CSO-DAC" ], "fedramp-rev5-class-c": [ "CM-5(1)", "CM-5(5)", "CM-3", "CM-3(2)", "CM-3(4)", "CM-4", "CM-4(2)", "CM-5" ], "fedramp-rev5-class-d": [ "CM-3(1)", "CM-5(1)", "CM-5(5)", "CM-3", "CM-3(2)", "CM-3(4)", "CM-4", "CM-4(2)", "CM-5" ], "fedramp-20x": [ "KSI-CMT-LMC", "KSI-CMT-RVP", "KSI-CMT-VTD", "KSI-SVC-PRR" ], "iso-27001": [ "A.8.32" ], "soc-2": [ "CC8.1" ], "pci-dss": [ "6.5" ], "nist-csf": [ "PR.PS-01", "ID.RA-07" ], "nist-800-171": [ "3.4.3", "3.4.4", "3.4.5" ], "nist-800-53": [ "CM-3", "CM-3(2)", "CM-3(4)", "CM-4", "CM-4(2)", "CM-5" ], "sox": [ "P9", "P11" ], "fedramp-rev5-class-b": [ "CM-4", "CM-5" ] } }, { "key": "vendor-management", "name": "Third-party / vendor risk management", "description": "Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data: the agreement obliges the vendor to comply in its own right with the security requirements that apply to it - an absolute standard, not a promise to match whatever you happen to do - to pass those obligations down to any subcontractor it brings in BY ENTERING INTO a contract or equivalent written arrangement with that subcontractor rather than by merely requiring equivalent practice of it, and to report to you, within a stated time, security incidents it becomes aware of and confirmed breaches of your data. Where a contract is not the instrument available, an equivalent written arrangement carrying the same obligations discharges the duty. The same obligations, together with the separation that keeps a related organization out of data it is not entitled to, are written into the governing document of any other arrangement that puts your data in the hands of a sponsor, parent, affiliate or plan. Diligence is not confined to security where the relationship warrants more: for suppliers significant enough to matter, the organization states the standards of conduct it expects of them - how they behave commercially and how they treat the environment around their operations - and screens candidates and incumbents against those stated expectations as part of the same selection and monitoring cycle, rather than accepting a signature on a code as evidence of it. Where the vendor handles personal data, the agreement binds it to privacy obligations no weaker than the commitments the organization has itself made about that data - the purposes it may be used for, the limits on passing it on further, and the help the organization needs in order to answer the requests individuals make about it - and the reporting duty above reaches a suspected as well as a confirmed compromise of that personal data, on the same stated clock. Which requirements apply to a given supplier is decided by the TYPE of relationship rather than by one clause set issued to everyone - what data it touches, what access it holds, whether it can affect the organization’s own service, and what it would cost if it failed - and the requirements are agreed and recorded before access begins rather than negotiated after go-live. Once the relationship is running, what the supplier actually delivers is reviewed against what was agreed on a stated cadence: the service records, the security reports and assurance the agreement entitles the organization to, the incidents it has declared, and the findings of any audit or test right the organization holds - exercised rather than merely retained. A change on the supplier’s side is managed as a change rather than discovered - a new subcontractor, a new location or jurisdiction, a change of ownership, a material change to the technology or to the people delivering the service is notified in advance under the agreement, assessed for what it does to the risk, and approved or refused before it takes effect. ACQUISITION is governed as its own act, under a documented system and services acquisition policy with supporting procedures, owned by a named role and reviewed on a defined cadence. When a system, a component or a service is bought, the contract states the security and privacy requirements it must meet - the functional requirements, meaning what the controls have to do; the strength requirements; the assurance requirements, meaning what evidence the supplier must produce that they work; the documentation the supplier must deliver and how it must be protected and distributed; the description of the development environment and of the environment the product will run in; and the acceptance criteria the delivery is measured against - all stated in the solicitation before a supplier is chosen rather than negotiated after award, and all expressed in terms of the applicable laws and standards. The supplier is required to describe the functional properties of the controls it will implement, and to provide design and implementation information for those controls at a level of detail the organization has specified, so the organization can judge them rather than take their existence on trust. It is also required to identify the functions, ports, protocols and other services the delivered product intends to use in the organization’s environment - and, for an external service provider, the ones its service requires - so an integration does not open a path nobody asked for. The program has three artifacts of its own. An INVENTORY of service providers lists every one the organization knows of, records the classification given to it and names the person inside the organization who owns the relationship, and is reviewed on a defined cadence and whenever a change to the organization would alter it. A POLICY governs the whole cycle - how providers are classified, how the inventory is kept, how they are assessed, how they are monitored and how they are decommissioned - owned by a named role and reviewed on the same terms. And a CLASSIFICATION is applied to each provider against stated criteria such as the sensitivity and volume of the data it holds, the availability the organization depends on it for, the regulation that reaches it, and the risk that remains after the controls in place - reviewed rather than assigned once. DECOMMISSIONING is performed rather than allowed to lapse: when a relationship ends, the user and service accounts are deactivated, the data flows into and out of the provider are terminated, and the organization’s data held in the provider’s systems is disposed of and the disposal evidenced. Who does what is settled before the relationship starts and written down on both sides: the cybersecurity roles and responsibilities of the organization, of the supplier, and of the customers and partners the arrangement reaches are established, communicated to each of them and coordinated between them, so a duty is not left in the gap where each party assumed the other held it. Planning and due diligence come before the agreement rather than after it - what the relationship would expose, what the candidate’s security actually looks like, and what would have to be true before it starts are established while declining is still an option. The risk a supplier carries is then held as a record rather than as an impression: understood, written down, prioritized against the other suppliers, assessed on a stated cadence, responded to with an owner and a date, and monitored for the whole life of the relationship instead of at onboarding only. The provider inventory records the SERVICES each one actually provides as well as its name, so what the organization has placed outside itself is answerable from the list. Where a PROCESS itself is provided from outside, it stays inside the management system’s control rather than leaving it: the controls the organization intends to apply to the external provider and the controls it intends to apply to the resulting output are defined separately and both are applied, because a well-governed supplier can still ship a nonconforming output. What the arrangement could do to the organization’s own ability to consistently meet its customers’ requirements is considered when those controls are set, and the verification or other activity necessary to establish that what arrives meets requirements is determined in advance and carried out rather than inferred from the supplier’s own assurances. Where a regime requires the CHAIN OF CUSTODY of a device to be established before it enters the environment, the organization documents and maintains that custody, replacement devices included, so the integrity of what arrives is demonstrated rather than assumed. The assurances the organization relies on exist as a DOCUMENT rather than as a conversation: they are recorded in the written contract or the equivalent written arrangement, they are in place before the data moves, and the duty runs in both directions - what the organization obtains from a provider before entrusting data to it, and what it obtains from its own subcontractor before allowing one to handle data that was entrusted to it. What that document must SAY is settled in advance rather than left to whichever template the provider sends. It states the uses and disclosures of the data the provider is permitted and required to make, and it does not authorize the provider to do anything with the data that the organization itself could not do - any exception for the provider’s own proper management and administration, or for aggregating data across its customers, being written in explicitly and bounded rather than assumed. It obliges the provider to report every use or disclosure the agreement did not provide for, breaches included, as soon as it becomes aware of one. It obliges the provider to support the rights the organization owes the people the data is about: making the data available for them to see, making it available for amendment and incorporating an amendment once made, and supplying whatever is needed to account for disclosures - and, where the provider carries out an obligation on the organization’s behalf, complying with the rules that would bind the organization in performing it. It obliges the provider to make its own internal practices, books and records relating to that data available to the regulator determining the organization’s compliance. It settles what happens at the end: the data is returned or destroyed and no copies kept, or, where that is genuinely not feasible, the agreement’s protections continue over whatever remains and further use of it is confined to the purposes that made return or destruction infeasible. And it gives the organization the right to TERMINATE for a material breach, because a termination right nobody negotiated is not available on the day it is needed. Flow-down is of the SAME TERMS and not of a thinner version of them: the agreement between the organization and its own subcontractor carries that content in the same manner as the agreement above it in the chain, so a subcontract is not the place the obligations get lighter. Knowing about a failure and carrying on is itself a failure. Where the organization becomes aware of a PATTERN of activity or practice by a provider that materially breaches or violates the provider’s obligations under the agreement, it takes reasonable steps to cure the breach or end the violation; where those steps do not work it TERMINATES the agreement, where termination is feasible; and where a regime requires the failure to be reported to a regulator instead of, or as well as, terminating, it makes that report. The same escalation runs one step down the chain where the organization is itself the provider and the pattern is its subcontractor’s. And it runs from the other side of the relationship too: where the organization holds data on somebody else’s behalf, it uses and discloses that data ONLY as its own agreement or the law permits, and never in a way that would breach the rules binding the organization it holds the data for if that organization did it - the sole exception being its own proper management and administration and the carrying out of its own legal responsibilities, and then only where the agreement actually permits it. That limit binds whatever the agreement says or omits, so a gap in the paperwork is not a licence. A BUSINESS TRANSACTION is governed as a disclosure in its own right rather than as the one occasion governance is suspended. Before any personal information moves between the parties to a PROSPECTIVE transaction, a written agreement is in place that requires the receiving party to use and disclose that information SOLELY for purposes related to the transaction, to protect it by security safeguards appropriate to its sensitivity, and - if the transaction does not proceed - to return it to the disclosing party or destroy it within a reasonable time; and what moves is confined to the information necessary to determine whether to proceed and, if the determination is to proceed, to complete the transaction, so a data room is scoped to the decision rather than filled with whatever was easy to export. If the transaction COMPLETES, a further agreement binds EACH party to use and disclose the information under its control solely for the purposes for which it was collected or was permitted to be used or disclosed before completion, to protect it by safeguards appropriate to its sensitivity, and to give effect to any withdrawal of consent; what is kept is necessary to carry on the business or activity that was the object of the transaction; and one of the parties NOTIFIES THE INDIVIDUALS, within a reasonable time after completion, that the transaction has been completed and that their personal information was disclosed under it - which is an act somebody has to own, schedule and evidence, not a clause that performs itself. Neither route is available where the primary purpose or result of the transaction is the purchase, sale, other acquisition or disposition, or lease, of the personal information itself, so a sale of a customer list is assessed on its own terms instead of inside a deal. And the terms of either agreement are obligations in their own right rather than the price of entry: they are complied with, monitored on the same cadence as any other supplier commitment, and carried into the receiving organization’s own operations after closing rather than filed with the deal documents.", "crosswalks": { "fedramp-rev5-class-c": [ "SA-9(1)", "SA-9(5)", "SA-1", "SA-4", "SA-4(1)", "SA-4(2)", "SA-4(9)", "SA-9", "SA-9(2)", "SR-3", "SR-6" ], "fedramp-rev5-class-d": [ "CP-8(4)", "SA-4(5)", "SA-9(1)", "SA-9(5)", "SA-1", "SA-4", "SA-4(1)", "SA-4(2)", "SA-4(9)", "SA-9", "SA-9(2)", "SR-3", "SR-6" ], "fedramp-20x": [ "KSI-SCR-MIT" ], "iso-27001": [ "A.5.19", "A.5.20", "A.5.22" ], "soc-2": [ "CC9.2", "P6.4", "P6.5" ], "nist-csf": [ "GV.SC-01", "GV.SC-02", "GV.SC-04", "GV.SC-05", "GV.SC-06", "GV.SC-07", "GV.SC-10", "ID.AM-04" ], "pci-dss": [ "12.8" ], "hipaa": [ "164.308(b)(3)", "164.314(a)(2)", "164.314(b)(2)", "164.502(a)(3)", "164.502(e)(2)", "164.504(e)(1)(ii)", "164.504(e)(1)(iii)", "164.504(e)(2)", "164.504(e)(5)" ], "iso-9001": [ "8.4.1", "8.4.2", "8.4.3" ], "esg-essentials": [ "G.7", "E.7" ], "cis-controls": [ "15.1", "15.2", "15.3", "15.4", "15.5", "15.6", "15.7" ], "gdpr": [ "Art.28(1)", "Art.28(3)" ], "nist-800-53": [ "SA-1", "SA-4", "SA-4(1)", "SA-4(2)", "SA-4(9)", "SA-9", "SA-9(2)", "SR-3", "SR-6" ], "coppa": [ "312.8(c)" ], "sox": [ "P11", "P15" ], "pipeda": [ "4.1.3", "7.2(1)", "7.2(2)", "7.2(3)" ], "fedramp-rev5-class-b": [ "SA-1", "SA-4", "SA-9", "SR-3" ] } }, { "key": "security-awareness-training", "name": "Security awareness training", "description": "Ongoing security and data-handling awareness training for all personnel, with completion tracking, and periodic security updates - reminders, bulletins and alerts - issued to the workforce between training cycles. New joiners are trained within a defined period of starting, anyone whose work is affected is retrained within a defined period after a material change to the policies or procedures, and every completion is recorded. The program itself rests on a documented awareness and training policy with supporting procedures, issued to the people and roles it binds, owned by a named role, and reviewed and updated on a defined cadence rather than at whatever point somebody notices it is stale. The curriculum names two threats explicitly, because both are answered by a person rather than by a system. The first is INSIDER THREAT: what the potential indicators look like - unexplained access outside a role, bulk copying, hostility after a disciplinary or a passed-over promotion, working around a control rather than raising it - and where to report a concern about a colleague, without the reporter being asked to conclude anything. The second is SOCIAL ENGINEERING AND SOCIAL MINING: the phishing message, the pretext phone call, the urgent request from an apparent executive, the person following somebody through a door, and the slower pattern of harmless-seeming questions that assembles into an answer nobody would have given at once - together with the instruction to report both the attempts that worked and those that did not. The curriculum is stated as a set of topics rather than left to whoever assembles the material. AUTHENTICATION: how multi-factor authentication works and why it is required, what makes a passphrase strong, and how credentials are stored and never shared. DATA HANDLING: how to identify sensitive information and how to store, transfer, archive and destroy it, together with the clear screen and clear desk habits that go with it - locking a screen on standing up, clearing a whiteboard at the end of a meeting, and putting paper and portable media away rather than leaving them out. UNINTENTIONAL EXPOSURE: the ways data leaves by accident, such as a message sent to the wrong recipient, a portable device left behind, or a file published to a wider audience than intended. INCIDENTS: how to recognize that something may be an incident and how to report it without first establishing that it is. MISSING UPDATES: how to tell that an asset is not receiving its security updates, and to report a failure of an automated patching tool rather than assume somebody is watching it. INSECURE NETWORKS: the risk of connecting to and sending organizational data over networks the organization does not control, including what is expected of a home network where people work from one. And beyond the common curriculum, ROLE-SPECIFIC training is given where a role carries specific risk - system administration, secure development, and the roles most likely to be targeted directly.", "crosswalks": { "fedramp-20x": [ "KSI-CED-RAT" ], "iso-27001": [ "A.6.3" ], "soc-2": [ "CC1.4" ], "nist-csf": [ "PR.AT-01", "PR.AT-02" ], "pci-dss": [ "12.6" ], "hipaa": [ "164.308(a)(5)(ii)(A)", "164.530(b)(2)" ], "esg-essentials": [ "S.5" ], "nist-800-171": [ "3.2.1", "3.2.2", "3.2.3" ], "cis-controls": [ "14.1", "14.2", "14.3", "14.4", "14.5", "14.6", "14.7", "14.8", "14.9" ], "gdpr": [ "Art.32(4)" ], "nist-800-53": [ "AT-1", "AT-2", "AT-2(2)", "AT-2(3)", "AT-3", "AT-4" ], "sox": [ "P4", "P14" ], "pipeda": [ "4.1.4", "4.2.5", "4.7.4" ], "fedramp-rev5-class-b": [ "AT-1", "AT-2", "AT-2(2)", "AT-3", "AT-4" ], "fedramp-rev5-class-c": [ "AT-1", "AT-2", "AT-2(2)", "AT-2(3)", "AT-3", "AT-4" ], "fedramp-rev5-class-d": [ "AT-1", "AT-2", "AT-2(2)", "AT-2(3)", "AT-3", "AT-4" ] } }, { "key": "asset-inventory", "name": "Asset inventory", "description": "An inventory of hardware, software, and information assets with assigned owners, in which the movement of equipment and removable media into, out of, and within the organization’s premises is recorded against the person responsible for it. The record is maintained by the acts that change it rather than by a periodic sweep: installing a component, removing one, or updating a system updates the inventory as part of that work, and the estate is scanned for hardware, software and firmware that is present but not authorized, with the response to an unauthorized component - disable its network access, isolate it, remove it, notify a defined role - decided in advance. The inventory answers WHERE INFORMATION IS as well as what exists: for the categories of information the organization has defined as sensitive, it records where that information is processed and stored, which system components host it, and which users and roles can reach it, and it is updated when any of those change - with automated tools used to locate that information across components and to confirm the required protections are actually in place there, rather than relying on what a system was designed to hold. Each asset also carries its support status: the date vendor support ends is recorded, and a component that reaches end of support is replaced, or is covered by an alternative source of continued support that the organization has arranged and recorded, rather than left in service because it still runs. The inventory is kept current by discovery as well as by the acts that change it: an active discovery tool interrogates the network on a defined frequency, a passive tool identifies assets from the traffic they generate, the DHCP and address-management logs are read on a defined cadence so an address issued to something nobody registered surfaces, and automated software-inventory tooling documents what is installed across the estate rather than relying on a manual return. Support status decides authorization rather than merely being recorded: only software the vendor still supports is designated authorized in the inventory, and software that is unsupported and carries no documented exception setting out its mitigating controls and the residual risk somebody accepted is designated unauthorized, so the process that removes unauthorized software picks it up. What the register holds about those categories of information is itself a DATA INVENTORY: for each data type the organization has designated, the record carries the metadata that makes it usable - what the data is, who owns it, how it is classified, where it came from, what it is retained for and for how long - so the question of what data exists is answered from the register rather than from the systems one at a time. And the register tracks lifecycle STATE as well as existence: each system, device, piece of software, service and data set carries where it has reached in its life - requested, acquired, deployed, in service, superseded, withdrawn, disposed of - with the acts that move it between those states recorded against it, so an asset is managed from acquisition through operation to disposal rather than entered once and forgotten.", "crosswalks": { "fedramp-rules-2026": [ "MAS-CSO-IIR" ], "fedramp-rev5-class-d": [ "CM-8(2)", "CM-8(4)", "CM-8", "CM-8(1)", "CM-8(3)", "CM-12", "CM-12(1)", "SA-22" ], "fedramp-20x": [ "KSI-PIY-GIV" ], "iso-27001": [ "A.5.9" ], "nist-csf": [ "ID.AM-01", "ID.AM-02", "ID.AM-07", "ID.AM-08" ], "pci-dss": [ "12.5" ], "hipaa": [ "164.310(d)(2)(iii)" ], "nist-800-171": [ "3.4.1" ], "cis-controls": [ "1.1", "1.2", "1.3", "1.4", "1.5", "2.1", "2.2", "2.4", "3.2" ], "nist-800-53": [ "CM-8", "CM-8(1)", "CM-8(3)", "CM-12", "CM-12(1)", "SA-22" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "CM-8", "SA-22" ], "fedramp-rev5-class-c": [ "CM-8", "CM-8(1)", "CM-8(3)", "CM-12", "CM-12(1)", "SA-22" ] } }, { "key": "data-classification", "name": "Data classification & handling", "description": "Information is classified and handled per its sensitivity, with rules for labeling and protection - including the everyday handling rules that stop it being seen, overheard or picked up by people with no business reading it, so exposure that happens incidentally alongside legitimate work is limited rather than accepted. The handling rules are written to cover disclosure that nobody intended as much as disclosure that somebody chose, they say what an unauthorized disclosure is against the organization’s own privacy and confidentiality rules rather than leaving that to judgment in the moment, and they reach every medium the information travels in - spoken, on paper, on a screen and in a system - because the incidental exposure they exist to limit does not respect the boundary between an administrative, a physical and a technical safeguard. Labeling is the procedure that makes the classification visible, and it is defined rather than left to habit: there is a label for each level of the scheme, a rule for how the label is applied in each form the information takes - a document, an email, a file, a database field, a screen, a report, a piece of removable media, a printed page - and, where a system supports it, the label is carried in metadata so it can be acted on automatically rather than only read. The person who creates or receives the information applies the label at that point rather than later, the label travels with the information when it is copied, extracted, exported or transferred so a copy does not arrive unclassified, and information derived from or aggregated out of classified sources is labeled for what the combination is worth rather than for what the least sensitive input was. Where a label would itself disclose something, an agreed alternative is used and recorded, and the procedure covers what to do when unlabeled information is found. On storage media the marking carries more than the level: it states the distribution limitations that apply and any handling caveats that travel with the contents, so somebody who picks the item up knows what they may do with it without having to ask. Where the organization exempts a class of media from marking because it never leaves a controlled area, that exemption is defined and recorded as a decision rather than practiced as an omission. Underneath the scheme sits a documented DATA MANAGEMENT PROCESS that the classification and the handling rules are derived from: it states how sensitivity is decided, who owns each category of data, how each category is handled, the retention limits that apply to it and what disposal it requires, and it is reviewed and updated on a defined cadence and whenever a change to the organization would alter it. That process is also what the DATA FLOWS are documented against - where each category of information originates, which systems and processes it moves between, and where it crosses out to a service provider - recorded as documentation somebody maintains rather than reconstructed when a question is asked, and reviewed on the same cadence.", "crosswalks": { "fedramp-rules-2026": [ "MAS-CSO-FLO", "MAS-CSO-MDI" ], "iso-27001": [ "A.5.12", "A.5.13" ], "soc-2": [ "C1.1" ], "nist-csf": [ "ID.AM-05" ], "pci-dss": [ "3.1" ], "hipaa": [ "164.530(c)(2)" ], "nist-800-171": [ "3.8.4" ], "cis-controls": [ "3.1", "3.7", "3.8" ], "gdpr": [ "Art.5(1)" ], "nist-800-53": [ "MP-3", "RA-2" ], "pipeda": [ "4.3.4", "4.7.2" ], "fedramp-rev5-class-b": [ "RA-2" ], "fedramp-rev5-class-c": [ "MP-3", "RA-2" ], "fedramp-rev5-class-d": [ "MP-3", "RA-2" ] } }, { "key": "physical-security", "name": "Physical security", "description": "Physical access to facilities and equipment holding sensitive data is restricted and monitored, and a person’s access is validated against the role or function that justifies it rather than only logged; visitors are controlled as a case of their own, and so is access to software programs held for testing and revision. The facility and the equipment in it are safeguarded against tampering and theft as well as against unauthorized entry, and so is the SUPPORT INFRASTRUCTURE the systems depend on - the power feed and its distribution, the cabling and patching, the cooling and environmental plant, the fire detection and suppression, and the points at which communications enter the building - which is protected and monitored on the same terms rather than treated as building services somebody else owns, because a system is stopped as surely by reaching its power or its cooling as by reaching its data. The people who have to reach the site and the equipment when a continuity or recovery plan is invoked can still get in, by a route that is planned rather than improvised; and repairs and modifications to the physical security components of a facility - doors, locks, walls, and the hardware that controls entry - are recorded. The offices, rooms and facilities themselves are designed and fitted for that job rather than simply occupied: rooms holding sensitive information or the equipment that processes it are sited away from public access and from routes people pass through for other reasons, the building’s signage, directories and public information do not advertise where sensitive processing happens, doors, windows, walls and any shared boundary with another tenant are specified against the risk the room actually carries, and a room is locked and checked when it is unoccupied rather than left secured by whoever was last out. Monitoring is continuous rather than periodic: the premises are watched for unauthorized physical access by detection suited to the site - intruder alarms, cameras, contact and motion detection, staffed reception or patrols - covering every way in including delivery and fire doors and including the hours nobody is there, with an alarm going to somebody who responds and a stated response. The monitoring system is protected in its own right, so its configuration, its coverage and its recordings cannot be altered or read by the people it is watching, and recordings are retained and handled under the privacy rules that apply to them. The detection is specified rather than generic: intrusion alarms and surveillance equipment are employed as the means of monitoring physical access, and what they cover, what raises an alarm and who responds is decided in advance. Visitors are escorted for the whole time they are inside a controlled area and their activity while there is monitored, rather than being signed in at a desk and then left to move around; that applies to contractors, delivery and service personnel and auditors alike, and where somebody is authorized to work unaccompanied that is a recorded decision rather than a courtesy. Visitors leave a record: who came, who they were visiting, when they arrived and left, and the identification presented; the record is retained for a defined period, reviewed on a defined cadence rather than only after an incident, and anomalies in it are reported to a designated role. Deliveries and removals are controlled as a class - system components and equipment entering or leaving the facility are authorized before they move, the movement is monitored, and a record of what came in and what went out is kept - and the delivery area itself is arranged so that a delivery does not become unescorted access to the interior. PHYSICAL ACCESS IS LOGGED and not only permitted: entry to the facility and to each controlled area inside it is recorded - who entered, which area, and when - by the entry system, the staffed reception, the visitor register or a combination of them, and the log is retained for a defined period and reviewed on a defined cadence, so a person can be placed in a room at a time and matched against what the systems in it recorded. PHYSICAL ACCESS DEVICES are managed as a controlled inventory rather than handed out: the keys, locks, combinations, badges, cards, fobs and biometric enrollments that open a door are listed with the holder of each, issue and return are recorded against that person, the inventory is reconciled on a defined cadence, and combinations are changed and locks re-keyed when a device is lost or stolen, when a holder leaves or moves, and on the cadence the organization has set rather than only after an incident. All of this rests on a documented physical and environmental protection policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence.", "crosswalks": { "fedramp-rev5-class-d": [ "PE-3(1)", "PE-6(4)", "PE-8(1)", "PE-1", "PE-2", "PE-3", "PE-6", "PE-6(1)", "PE-8", "PE-16" ], "nist-csf": [ "PR.AA-06", "DE.CM-02" ], "iso-27001": [ "A.7.1", "A.7.2", "A.7.3", "A.7.4" ], "soc-2": [ "CC6.4" ], "pci-dss": [ "9.1", "9.2", "9.3" ], "hipaa": [ "164.310(a)(2)(i)", "164.310(a)(2)(ii)", "164.310(a)(2)(iii)", "164.310(a)(2)(iv)" ], "gdpr": [ "Art.32(1)" ], "nist-800-171": [ "3.10.1", "3.10.2", "3.10.3", "3.10.4", "3.10.5" ], "nist-800-53": [ "PE-1", "PE-2", "PE-3", "PE-6", "PE-6(1)", "PE-8", "PE-16" ], "sox": [ "P11" ], "pipeda": [ "4.7.3" ], "fedramp-rev5-class-b": [ "PE-1", "PE-2", "PE-3", "PE-6", "PE-8", "PE-16" ], "fedramp-rev5-class-c": [ "PE-1", "PE-2", "PE-3", "PE-6", "PE-6(1)", "PE-8", "PE-16" ] } }, { "key": "secure-development", "name": "Secure software development", "description": "Security is built into how software is specified, written, reviewed, tested, released and maintained, and the lifecycle is defined so that a team knows at which point each security activity happens rather than fitting them in where there is room. Underneath that sits a secure coding standard the organization actually maintains: it exists for each language and platform in use, is based on a recognized source plus what the organization’s own defects and incidents have taught it, and is versioned and dated. It applies at three points. Before coding - developers are competent in it and trained on it, the environment is set up so the insecure option is the harder one, and the components and frameworks a project may build on are chosen and pinned rather than picked up. During coding - it gives concrete direction on the failure classes that actually recur: untrusted input and injection, output encoding, authentication and session handling, authorization decided on the server, memory and resource handling, error handling that does not disclose internals, use of cryptographic functions, and keeping credentials and keys out of source. After coding - code is read by somebody other than its author before it merges, and automated analysis runs in the pipeline rather than on request. Third-party and open-source components are held to the same standard, kept at supported versions, and reviewed when a new advisory affects them. Legacy code is brought up to the standard as it is touched rather than exempted permanently, and the standard itself is revised as languages, platforms and attacks change. Where development is performed by a supplier, the same expectations are conditions of the engagement: the developer follows a documented development process that explicitly addresses security and privacy requirements, identifies the standards and tools it uses and the specific options and configurations of those tools, and documents and manages any change to the process or the tooling during development - and the organization reviews that process, those standards, those tools and their options on a defined cadence to confirm they still satisfy what it requires. The developer also performs a criticality analysis at the decision points in the life cycle the organization has named, at the level of rigor it has specified, so the components and functions that matter most are identified while the design can still change. Developer training is given at least annually rather than once at induction, and is designed to build a security culture in the team rather than to record a completion. And a fixed vulnerability is not a finished one: ROOT CAUSE ANALYSIS is performed on security vulnerabilities found in the organization’s own code, so the underlying issue that produced the defect - a missing validation habit, an unsafe helper, a design that made the wrong thing easy - is identified and addressed rather than the team moving from one individual fix to the next. How well the practices are working is MONITORED across the lifecycle rather than assumed from their existence: the security activities at each stage carry a measure somebody actually reads - what the automated analysis found and how quickly it was acted on, what code review caught, what reached production and had to be fixed there - and the results are reviewed for what they say about the process, so the standard is adjusted for the defects it is not catching. The data management process is issued as well as written: it goes to the people who create, hold and handle each category, it names the role answerable for each category rather than leaving ownership collective, and it is kept current so that what people work to is what the organization has decided rather than what it decided the last time somebody looked. How these protections are applied is written down as procedure rather than left as intent: which paths and which stores are in scope, which protocols, algorithms, key strengths and certificate sources are acceptable and which are no longer, how an exception is requested and approved and for how long, and who owns each decision - kept current as the cryptography ages, issued to the engineers and administrators who configure it, and reviewed on a defined cadence so that what people build to is the current standard. The arrangements are documented as policy and operating procedure rather than carried in the heads of the people who set them up: what is deployed on which system types, the update and scan cadences, who administers the tooling, who acts on a detection and within what time, and how a system type judged not to be at risk is re-evaluated - kept current, in use by the people it binds, known to them, and owned by named roles. All of it is documented rather than customary: the lifecycle, the standard and the activities hung off them are written down, kept current as the platforms and the attacks move, in use by the teams they bind rather than filed, known to the engineers doing the work, and owned by named roles rather than by the team collectively. How the organization tests itself is written down as a regime rather than practiced as a set of habits: which tests run against which scope, at what frequency, who performs each of them, who receives the results, and what has to happen to a finding and by when - documented, kept current, in use, known both to the people who run the tests and to those who act on what they find, with the roles and responsibilities for each assigned rather than assumed. The decisions are carried by an access control system rather than by convention: it reaches every component in scope, it resolves each request against the permissions assigned to the individual, application or system making it - assigned from the job classification and function the organization recorded, not from what the requester asked for - and it is set to refuse by default, so a request no rule permits is denied rather than allowed because nobody wrote a rule against it. Where an obligation sets a floor under the history rather than leaving the period to the organization - a stated number of months of records, of which a shorter recent window has to be immediately available to query rather than restorable from an archive - the store is configured to that floor, the fast window is sized for it, and the restore path for the older portion is tested rather than assumed to work. THE ALERTING REACHES THE OTHER CONTROLS and not only the logging pipeline: a failure of any control the organization has designated critical - the network filtering, the intrusion detection, the anti-malware, the change-detection mechanism, the physical and the logical access systems, the segmentation that bounds a sensitive environment - is detected promptly rather than at the next review, raised to a named role, and worked under a documented response that records what failed, what caused it, how long it was down, what was done to protect the environment while it was, and what was changed so it does not happen again.", "crosswalks": { "fedramp-rev5-class-c": [ "IA-5(7)", "SA-3", "SA-8", "SA-11", "SA-15", "SA-15(3)" ], "fedramp-rev5-class-d": [ "IA-5(7)", "SA-3", "SA-8", "SA-11", "SA-15", "SA-15(3)" ], "fedramp-20x": [ "KSI-CMT-VTD", "KSI-PIY-RSD" ], "nist-csf": [ "PR.PS-06" ], "iso-27001": [ "A.8.25", "A.8.28" ], "soc-2": [ "CC8.1" ], "pci-dss": [ "6.1", "6.2" ], "cis-controls": [ "16.1", "16.3", "16.5", "16.9", "16.12" ], "nist-800-53": [ "SA-3", "SA-8", "SA-11", "SA-15", "SA-15(3)" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "SA-3", "SA-8" ] } }, { "key": "network-security", "name": "Network security controls", "description": "Firewalls/segmentation and network controls restrict traffic to and from sensitive environments. The networks themselves are managed as assets with owners: what exists is documented, traffic is permitted by rule rather than by default, the rules are reviewed and the ones nobody can justify are removed, and each device connecting is uniquely identified and authenticated before the connection is established, rather than trusted for being on the wire. NETWORK SERVICES are treated as a separate question from the network itself, and the same question is asked whether the service is run in-house or bought: for each one - connectivity and transit, remote access, name resolution, filtering, load balancing and delivery, wireless, voice and real-time communications - the organization identifies the security mechanisms it must apply, the service levels it must meet and the management requirements that come with it, and writes them into the agreement with the provider or into the internal service definition before anything depends on it. That includes what authentication, encryption and connection controls the service enforces, the availability and capacity it commits to, who may connect and how that is decided, what it monitors and reports and to whom, and the organization’s right to verify that what was agreed is what is delivered. Services are reviewed against those terms on a cadence, and a service that cannot demonstrate them is treated as a recorded risk rather than as a working arrangement. All of it rests on a documented system and communications protection policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. THE BOUNDARY is drawn narrowly and deliberately: the number of external connections into the organization’s systems is limited rather than allowed to accumulate, each external telecommunications service terminates on a managed interface that enforces the organization’s traffic flow policy, and any exception granted to that policy is documented with the need it serves, the systems it applies to and a duration, and is reviewed and removed when the need ends. Connections BETWEEN the organization’s own system components are governed on the same terms rather than trusted for being internal: each is individually authorized, its interface characteristics, security requirements and the nature of the information communicated are documented, the conditions under which it will be terminated are stated in advance, and its continued need is reviewed on a cadence. A network connection is torn down at the end of the session it serves, or after a defined period of inactivity, rather than left open until something else closes it. Components the public can reach - the website, the mail and web gateways, the API front end, anything published to the internet - sit on subnetworks physically or logically separated from the internal network, so reaching a public component does not place the caller inside the estate behind it. WHERE INFORMATION ITSELF MAY TRAVEL is controlled as well as the traffic that carries it: the flows permitted for each classification of information - between internal systems, out to an external party, from a more trusted zone into a less trusted one, and out of the organization altogether - are decided in advance and recorded as approved authorizations, and the enforcement points are configured to those authorizations rather than to a general instruction to be careful, so an unapproved flow is blocked by a rule somebody wrote instead of being permitted because nobody wrote one. VOICE AND REAL-TIME COMMUNICATIONS are governed as a service in their own right rather than as ordinary traffic: usage restrictions and implementation guidance are written for Voice over IP and the conferencing and messaging platforms beside it, a deployment is authorized before it carries a call, and its use is monitored and controlled - because a softphone, a conferencing bridge or a SIP trunk is a path for audio out of a room and a route into the network, not only a convenience. Availability is defended as well as confidentiality: the effects of denial-of-service events - the types the organization has decided it must withstand - are limited or absorbed by controls chosen for that purpose, with the capacity and the protective mechanisms sized against a stated expectation rather than against the traffic seen so far. NAME AND ADDRESS RESOLUTION is treated as security infrastructure. Where the organization is authoritative for a namespace, its responses carry data origin authentication and integrity verification artifacts so a resolver can validate them, and the security status of each child zone is published along with the material needed to verify the chain when a child zone is operated separately. Where the organization resolves names, its resolvers request and verify those artifacts on the responses they receive from authoritative sources rather than accepting an answer because it arrived. The resolution service itself is architected for fault tolerance and separates its internal and external roles, so an outage or a compromise on one side does not carry to the other. THE NETWORK ESTATE IS MAINTAINED as an asset in its own right. Devices run releases the vendor still supports, and their versions are reviewed on a defined cadence so end of support arrives as a planned replacement; their configuration is held as version-controlled infrastructure-as-code and their management interfaces are reached only over protocols that authenticate and encrypt the session; authentication, authorization and accounting for network access are centralized rather than held device by device; and the protocols used for management and for carrying traffic are chosen from those still considered sound rather than from those the equipment happens to default to. Architecture diagrams and the supporting network documentation are maintained and reviewed on a defined cadence rather than drawn once at build. Name resolution is pointed somewhere trusted: assets resolve through resolvers the organization controls or has decided are reputable, rather than through whatever a network hands them. DETECTION AND ENFORCEMENT sit in the path as well as beside it. Intrusion detection watches network traffic for malicious activity; intrusion prevention blocks it where the organization has decided blocking is appropriate; traffic is filtered at the application layer through a proxy, application-layer firewall or gateway where a port-and-address decision is not enough; and access is controlled at the port a device connects to, the device authenticating by 802.1X or an equivalent before it is on the network rather than being trusted for having reached a socket. The documentation is kept as an explicit REPRESENTATION of what is authorized: the network communication the organization permits, and the data flows inside its own estate and across its boundary to external parties, are drawn and maintained as a current picture rather than reconstructed from firewall rules when somebody asks for one. The networks and the network services running on them are monitored on the same terms, so a potentially adverse event - an unexpected flow, a service behaving unlike its baseline, traffic to somewhere nothing should be talking to - is found by watching rather than reported by its consequences. TRUSTED AND UNTRUSTED is a boundary with two directions rather than one: traffic entering the estate from any network the organization does not control is admitted only where a rule allows it, traffic leaving for such a network is restricted on the same terms rather than permitted for having originated inside, and a packet arriving from outside that claims an internal source address is discarded at the boundary rather than routed on the strength of what it says about itself.", "crosswalks": { "fedramp-rev5-class-c": [ "SC-7(18)", "AC-4", "CA-9", "IA-3", "SC-1", "SC-5", "SC-7", "SC-7(3)", "SC-7(4)", "SC-7(5)", "SC-10", "SC-20", "SC-21", "SC-22" ], "fedramp-rev5-class-d": [ "AC-4(4)", "SC-7(18)", "SC-7(20)", "SI-4(22)", "AC-4", "CA-9", "IA-3", "SC-1", "SC-5", "SC-7", "SC-7(3)", "SC-7(4)", "SC-7(5)", "SC-10", "SC-20", "SC-21", "SC-22" ], "fedramp-20x": [ "KSI-CNA-MAT", "KSI-CNA-RNT", "KSI-CNA-RVP", "KSI-CNA-ULN" ], "iso-27001": [ "A.8.20", "A.8.21", "A.8.22" ], "soc-2": [ "CC6.6" ], "nist-csf": [ "PR.IR-01", "ID.AM-03", "DE.CM-01" ], "pci-dss": [ "1.1", "1.2", "1.3", "1.4", "11.5" ], "nist-800-171": [ "3.1.3", "3.13.1", "3.13.5", "3.13.6", "3.13.9", "3.13.14" ], "cis-controls": [ "4.4", "4.5", "4.9", "12.1", "12.2", "12.3", "12.4", "12.5", "12.6", "13.3", "13.4", "13.8", "13.9", "13.10" ], "nist-800-53": [ "AC-4", "CA-9", "IA-3", "SC-1", "SC-5", "SC-7", "SC-7(3)", "SC-7(4)", "SC-7(5)", "SC-10", "SC-20", "SC-21", "SC-22" ], "sox": [ "P11" ], "fedramp-rev5-class-b": [ "CA-9", "SC-1", "SC-5", "SC-7", "SC-20", "SC-21", "SC-22" ] } }, { "key": "data-retention-disposal", "name": "Data retention & secure disposal", "description": "Data is retained per policy and securely destroyed when no longer needed. Retention periods are set against the purpose the data was collected for and any legal or contractual obligation to keep it, recorded per category of data rather than left to whoever is looking at the record, and enforced when they run out - data goes because its period ended, not because somebody finally objected to keeping it. Destruction leaves it unrecoverable rather than merely removed from an index, and what was destroyed, when, by what method and on whose authority is recorded. The hardware and media that held it reach a defined final disposition at end of life, by a route the organization has decided in advance rather than by whatever happens to the box; and any media that stays in service is cleared of that data before it is reused, reassigned, or passed to anyone else. Disposal is not confined to data and media: the documentation, the tools and the system components the organization has defined as needing it are disposed of by techniques and methods it has approved in advance - so a decommissioned appliance, a retired build server, a set of network diagrams or a licensed utility leaves the organization by a route somebody chose, and the route is recorded on the same terms as a data destruction. A retention period has two ends and both are stated: the minimum the organization must keep the data for, and the maximum beyond which it may not be kept - so retention is bounded in the direction of keeping too long as well as of destroying too early. Death does not take a record out of scope. Where a regime continues its protections over the information of a person who has died, that continuation is recorded on the schedule as a SCOPE fact and not as a retention period: for as long as it runs, those records are governed on the same terms as a living person’s, and it is measured from the DATE OF DEATH rather than from the last transaction, so the category cannot quietly be treated as out of scope once the file stops moving. It is not an instruction to keep anything. How long the records are held is still decided by the purpose they were collected for and by whatever law actually sets a retention minimum over them; disposing of them when that period ends stays available, and what the continuation governs is how they are handled for as long as they are held - disposal included, so the destruction of a deceased person’s record has to meet the same requirements as any other. Under HIPAA that continuation runs for FIFTY YEARS after the date of death. It is a separate duty from the six-year period the same regime places on the documentation an organization keeps about its own compliance, which is a real retention minimum over compliance records and not over a person’s health record, and NEITHER of them sets a minimum retention period for the health record itself - so a schedule that reads either as one is working from a rule the regime does not state.", "crosswalks": { "fedramp-rev5-class-d": [ "MP-6(1)", "MP-6(2)", "MP-6", "SI-12", "SR-12" ], "fedramp-20x": [ "KSI-SVC-RUD" ], "iso-27001": [ "A.7.14", "A.8.10" ], "soc-2": [ "C1.2", "CC6.5", "P4.2", "P4.3" ], "pci-dss": [ "3.2" ], "hipaa": [ "164.310(d)(2)(i)", "164.310(d)(2)(ii)", "164.502(f)" ], "cis-controls": [ "3.4", "3.5" ], "gdpr": [ "Art.5(1)" ], "nist-800-171": [ "3.8.3" ], "nist-800-53": [ "MP-6", "SI-12", "SR-12" ], "us-employment-federal": [ "us.recordkeeping.eeo", "us.recordkeeping.i9-retention" ], "coppa": [ "312.10" ], "pipeda": [ "4.5", "4.5.2", "4.5.3", "4.7.5", "8(8)" ], "fedramp-rev5-class-b": [ "MP-6", "SI-12", "SR-12" ], "fedramp-rev5-class-c": [ "MP-6", "SI-12", "SR-12" ] } }, { "key": "hr-security", "name": "Personnel security (HR)", "description": "Background screening, confidentiality agreements, and onboarding/offboarding security steps. Before a person is given access to sensitive data, and again whenever their role changes, a documented determination is made that the access their work calls for is appropriate to it - the screening informs that decision but is not the decision. What screening may ask is itself bounded: inquiries about a candidate’s health, disability or medical history are not made, and medical examinations are not required, before a conditional offer of the role has been made, and where such inquiries or examinations are made after an offer they are applied to everyone entering that role rather than to the individuals somebody chose to ask. Access is ended when their employment, or any other arrangement under which they worked for the organization, comes to an end, and whenever that determination says they should no longer hold it. The security responsibilities a person carries are stated in the terms under which they are engaged - in the employment contract or the equivalent agreement for a contractor or temporary worker - together with the organization’s own obligations to them, the duties that continue after the engagement ends and for how long, and what happens if the terms are broken; the terms are accepted before access is given. At the end of an engagement, and on a change of role that removes the need, every asset the person holds is returned and the return is recorded against the inventory rather than assumed - devices, media, tokens and keys, documents and any organization information held on equipment they own - and where information exists only on equipment the organization is not taking back, its transfer and deletion are performed and confirmed before the person leaves. The practice is governed by a documented personnel security policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. Security and privacy responsibilities are written into the POSITION DESCRIPTION for each role rather than only into the contract everybody signs, so what a particular job is accountable for is visible when it is advertised, filled, evaluated and re-scoped - and the descriptions are revised when the responsibilities change. Where a regime requires any NATIONALITY condition attaching to a role or to an account type to be written down, the organization documents the condition, and documents explicitly that there is none where none applies. Silence and a recorded absence are not the same record, and only the second can be verified.", "crosswalks": { "fedramp-rev5-class-c": [ "PS-3(3)", "PS-1", "PS-2", "PS-3", "PS-6", "PS-7", "PS-9" ], "fedramp-rev5-class-d": [ "PS-3(3)", "PS-1", "PS-2", "PS-3", "PS-6", "PS-7", "PS-9" ], "nist-csf": [ "GV.RR-04" ], "iso-27001": [ "A.5.11", "A.6.1", "A.6.2", "A.6.5" ], "soc-2": [ "CC1.4" ], "pci-dss": [ "12.7" ], "hipaa": [ "164.308(a)(3)(ii)(B)", "164.308(a)(3)(ii)(C)" ], "gdpr": [ "Art.32(4)" ], "nist-800-171": [ "3.9.1" ], "nist-800-53": [ "PS-1", "PS-2", "PS-3", "PS-6", "PS-7", "PS-9" ], "us-employment-federal": [ "us.hiring-onboarding.ada-preoffer", "us.hiring-onboarding.fcra-background" ], "sox": [ "P4" ], "fedramp-rev5-class-b": [ "PS-1", "PS-2", "PS-3", "PS-6", "PS-7", "PS-9" ] } }, { "key": "security-privacy-officers", "name": "Named security & privacy officers", "description": "One named individual is accountable for developing and implementing the organization’s security policies and procedures, and one for the policies and procedures governing personal data - the same person where the organization is small enough that saying so is honest. A named contact point receives questions and complaints about how personal data is handled. The same naming discipline runs down through the rest of the program: the responsibilities and authorities for the security duties the organization depends on are assigned by leadership to named roles - including who answers for the management system meeting its requirements and who reports on how it is performing to leadership - and each holder is told what they hold and what they may decide, as are the people who have to go to them. Every designation and assignment is recorded in writing, published where the people who need it will find it, kept current as roles change, and reviewed when the organization changes shape. The same discipline is applied to the security duties themselves rather than only to the senior posts: the organization works out which information security responsibilities exist across the whole of it - who owns each asset and each information-handling process, who decides on a risk, who administers each control, who reviews access, who handles an event - and allocates every one of them to a role sized to what the organization actually needs rather than to an org chart it copied. The allocation is checked for gaps and for conflicts, so no duty is left with a role that no longer exists and no single role holds two that should be held apart, and a duty is reallocated when its holder leaves rather than lapsing with them.", "crosswalks": { "iso-27001": [ "5.3", "A.5.2" ], "hipaa": [ "164.308(a)(2)", "164.530(a)(2)" ], "pipeda": [ "4.1", "4.1.1", "4.1.2", "6" ] } }, { "key": "disciplinary-process", "name": "Disciplinary & sanctions process", "description": "A defined process for acting on a member of the workforce who breaches the organization’s security or personal-data policies: how a suspected breach is established, who decides, what range of sanctions is available and how the response is kept proportionate to what was done, and who is told when a sanction is initiated. Each sanction applied is recorded. The workforce is told the process exists and will be used, because a sanction nobody knew was possible deters nobody.", "crosswalks": { "iso-27001": [ "A.6.4" ], "hipaa": [ "164.308(a)(1)(ii)(C)", "164.530(e)(2)" ], "nist-800-53": [ "PS-8" ], "fedramp-rev5-class-b": [ "PS-8" ], "fedramp-rev5-class-c": [ "PS-8" ], "fedramp-rev5-class-d": [ "PS-8" ] } }, { "key": "data-segregation", "name": "Segregation of regulated data inside a larger organization", "description": "Where a function that carries its own regulatory duties runs inside a larger organization or on shared infrastructure, the data it holds is kept logically separate from the rest of that organization - separate stores or partitions, separate access groups, and a default denial for anyone outside the function - so the wider organization cannot reach the data without being separately and deliberately authorized to. The same separation is applied by data sensitivity and not only by regulatory function: processing and storage are segmented so that information of one sensitivity is not handled on assets provisioned for a lower one, and an asset built for low-sensitivity work does not become the place sensitive data is processed because it was the one available.", "crosswalks": { "fedramp-rev5-class-c": [ "AC-4(21)" ], "fedramp-rev5-class-d": [ "AC-4(21)", "SC-7(21)" ], "cis-controls": [ "3.12" ], "hipaa": [ "164.308(a)(4)(ii)(A)" ] } }, { "key": "endpoint-security", "name": "Workstation & endpoint security", "description": "The devices people use to reach sensitive data are governed on three axes. What may be done on them and how - the permitted functions, software and networks, and the way each is to be carried out. Where they may be used - the physical surroundings a screen can be overlooked from, and what has to be true of a place before work happens there. And how the device itself is protected so only authorized users reach it - screens and desks cleared when unattended, devices locked down or taken with the person when they leave. Two separate mechanisms run here and a screen lock does not stand in for the other. A device left idle LOCKS after a defined period, concealing what is on screen, and stays locked until the user re-establishes access through identification and authentication. Separately, a user session on an application or system holding sensitive data is automatically TERMINATED - torn down, not merely obscured - so it cannot be resumed by whoever is at the keyboard. The conditions and trigger events that require termination are defined by the organization and written down rather than left to be inferred: a predetermined period of user inactivity is one of them and is the one required wherever health data is in scope, but the set also reaches a targeted response to particular kinds of incident and restrictions on the time of day a system may be used. The automatic mechanisms do not excuse the person: users are required to log out when the organization’s stated conditions apply - at the end of a period of expected inactivity, and when leaving the device where somebody else could reach it - so the timer is a backstop rather than the control. What the lock puts on the screen is decided too: the display is replaced with a publicly viewable image that discloses nothing about what was there, rather than dimmed or left showing the last window.", "crosswalks": { "fedramp-rev5-class-c": [ "SC-7(12)", "SI-4(23)", "AC-2(5)", "AC-11", "AC-11(1)", "AC-12" ], "fedramp-rev5-class-d": [ "SC-7(12)", "SI-4(23)", "AC-2(5)", "AC-11", "AC-11(1)", "AC-12" ], "cis-controls": [ "4.3" ], "iso-27001": [ "A.7.7", "A.8.1" ], "hipaa": [ "164.310(b)", "164.310(c)", "164.312(a)(2)(iii)" ], "nist-800-171": [ "3.1.10", "3.1.11" ], "nist-800-53": [ "AC-2(5)", "AC-11", "AC-11(1)", "AC-12" ] } }, { "key": "data-integrity", "name": "Data integrity verification", "description": "Mechanisms that would actually detect sensitive data being altered or destroyed without authorization, rather than assuming it has not been: checksums, hashes or digital signatures computed over stored records and re-verified rather than written once; integrity monitoring over the files and systems holding them; integrity verification of the software and firmware those systems run - signed packages and images, and detection of unauthorized change to executables, configuration and device firmware, because data that verifies clean under code that does not is not verified at all; and integrity protection on data in transit, so a change made between sender and receiver is detected before the data is relied on. A failed check raises an alert to someone who investigates it, and what was found is recorded. The checks run on a stated schedule and at stated events - at startup, at a defined transitional state, on a defined frequency, and when a security-relevant change occurs - rather than only when somebody suspects something. And detection of an unauthorized change is wired into the incident process rather than into a report: a positive result raises an incident under the organization’s incident response capability, with the same assessment, containment and record-keeping as any other incident, so an integrity alert is handled rather than filed. The same verification is applied to what is RESTORED: after a recovery, the integrity of the restored data, software and configuration is checked against known-good values before the system is handed back to use, the services are brought back in the order the plan sets, and normal operating status is confirmed by test rather than inferred from the system having started. WHICH FILES sit under that monitoring is decided and listed rather than inferred: the executables, the configuration and the content whose unexpected modification would matter, and the system files an intrusion would have to touch - each compared against a known-good baseline on a cadence the organization has stated and can defend, with a named role assigned to act on every alert the comparison raises.", "crosswalks": { "fedramp-rev5-class-c": [ "SI-6", "SI-7", "SI-7(1)", "SI-7(7)" ], "fedramp-rev5-class-d": [ "SI-6", "SI-7(2)", "SI-7(5)", "SI-7", "SI-7(1)", "SI-7(7)" ], "fedramp-20x": [ "KSI-SVC-VCM", "KSI-SVC-VRI" ], "nist-csf": [ "RC.RP-05" ], "pci-dss": [ "11.5" ], "hipaa": [ "164.312(c)(2)", "164.312(e)(2)(i)" ], "nist-800-53": [ "SI-7", "SI-7(1)", "SI-7(7)" ] } }, { "key": "quality-policy", "name": "Quality policy & objectives", "description": "Top management establishes a quality policy that suits the organization’s purpose and context and supports its strategic direction, provides a framework for setting quality objectives, commits to satisfying applicable requirements, and commits to continual improvement of the quality management system. The policy is maintained as documented information, communicated inside the organization in a form people can act on, understood rather than merely circulated, and made available to relevant interested parties where that is appropriate. Quality objectives are set from it at the functions, levels and processes the system needs them at: consistent with the policy, measurable, taking account of applicable requirements, relevant to conformity of products and services and to enhancing customer satisfaction, monitored, communicated, and updated as things change. Each objective is planned rather than declared - what will be done to achieve it, what resources that will require, who is responsible for it, when it is to be completed, and how the results will be evaluated - and the objectives are maintained as documented information so the plan behind a number is retrievable rather than remembered.", "crosswalks": { "iso-9001": [ "5.2.1", "5.2.2", "6.2.1", "6.2.2" ] } }, { "key": "risk-opportunity-planning", "name": "Risk & opportunity planning", "description": "Working from the organization’s context and what its interested parties require, the risks and opportunities the management system must address are determined and recorded; an action is planned for each and built into the system’s own processes rather than run alongside them; and those actions are afterwards evaluated for whether they worked, in proportion to the potential impact of the risk or opportunity. Opportunity is treated as the other side of the same determination rather than as a separate exercise: the strategic opportunities open to the organization - the positive risks - are characterized in the same terms as the negative ones and brought into the same discussion, so a decision to accept a risk in order to take an opportunity is made once, in one place, with both sides of it visible.", "crosswalks": { "nist-csf": [ "GV.RM-07" ], "iso-9001": [ "6.1.1", "6.1.2" ], "iso-42001": [ "6.1.1" ] } }, { "key": "document-control", "name": "Document & records control", "description": "Documented information is created, approved, versioned, and controlled; records are retained and protected for a defined minimum period - measured from the document’s creation OR from the date it last was in effect, whichever is later, so a policy that stayed in force for years does not start its clock on the day it was written - and are available to the people who have to act on the procedures they describe. Documentation is reviewed on a schedule and updated when an operational, environmental or legal change has made the current version wrong. A change forced by law is documented and put into effect promptly, and where that legal change materially affects what the organization has published to individuals about how it handles their data, THAT NOTICE IS REVISED TOO, as part of the same prompt action rather than as a separate task left to whoever owns the notice. Any other change may be made at any time provided the revised version still complies and IS DOCUMENTED BEFORE THE CHANGE TAKES EFFECT - the record precedes the effective date, so a routine that documents changes in arrears does not discharge this. Records are protected for as long as they are kept, and against more than deletion: against loss, against destruction, against falsification, against being read by somebody with no entitlement to them, and against being released outside the organization without authority. The protection applied to a class of record is decided from the requirements attached to it - what the law, the regulator or the contract demands of that record type, and what it would cost if it were lost or altered - rather than from where it happens to be stored. Records are held so that a change to one is attributable and detectable rather than silent, the storage medium and format are chosen to remain readable for the whole retention period and the information is migrated before either stops being so, and the ability to retrieve a record intact is exercised rather than assumed. What the set of documented information consists of is itself a decision rather than an accumulation: it comprises the documented information the standard the system is built against explicitly requires, plus whatever else the organization determines is necessary for the system to be effective - and the second half is decided against the size of the organization and the kind of activity, product and service it deals in, the complexity of its processes, and the competence of its people, so a small organization is not judged against a large one’s binder and a large one cannot claim a small one’s.", "crosswalks": { "fedramp-rules-2026": [ "SCG-ENH-VRH" ], "iso-9001": [ "7.5.1", "7.5.2", "7.5.3.1", "7.5.3.2" ], "soc-2": [ "CC5.3" ], "iso-27001": [ "7.5", "A.5.33", "A.5.37" ], "hipaa": [ "164.316(b)(2)(i)", "164.316(b)(2)(ii)", "164.316(b)(2)(iii)", "164.530(i)(3)", "164.530(i)(5)", "164.530(j)(2)" ], "sox": [ "P12" ], "iso-42001": [ "7.5" ] } }, { "key": "competence-management", "name": "Competence management", "description": "The competence each role in the management system needs is determined and written down, and the people in those roles are established as having it - on the basis of their education, training or experience rather than on the basis of holding the job. Where the competence is not there, something is done about it - training, mentoring, supervision, reassignment or hiring - and the action is afterwards evaluated for whether it produced the competence, not merely for whether it was delivered. The records that show all of this are retained.", "crosswalks": { "iso-27001": [ "7.2" ], "iso-9001": [ "7.2" ], "sox": [ "P4" ], "iso-42001": [ "7.2" ] } }, { "key": "management-system-awareness", "name": "Management-system awareness", "description": "Everyone doing work under the organization’s control can say what the policy governing their work commits to, which of the objectives their own work affects, how what they do contributes to the management system working - including what improving it is worth - and what the consequences are when its requirements are not met.", "crosswalks": { "iso-9001": [ "7.3" ], "iso-27001": [ "7.3" ], "iso-42001": [ "7.3" ] } }, { "key": "internal-audit-program", "name": "Internal audit program", "description": "A risk-based internal audit program evaluates conformity and effectiveness at planned intervals, and again when an environmental or operational change could have undermined what was last evaluated; each evaluation covers both technical testing and non-technical review of whether the documented policies and procedures are actually being met. The program itself is written down - how often audits run, what methods they use, who is responsible for them, what each one covers and how it reports - and nobody audits their own work, so a finding is an independent judgment rather than a self-assessment. The results of each audit go to the management responsible for the area audited, and the program and its results are retained as evidence that it ran. It rests on a documented assessment, authorization and monitoring policy with supporting procedures, issued to the roles it binds, owned by a named official, and reviewed and updated on a defined cadence. Independence is a property of the assessor and not only of the reporting line: assessments are carried out by assessors or assessment teams with no responsibility for what they are assessing and no stake in the result - internal to the organization but outside the area, or brought in from outside it - and the organization states what level of independence it requires before the assessment is commissioned rather than judging it afterwards. That independence extends to the ongoing case as well as the scheduled one: where controls are monitored continuously between audits, independent assessors monitor them too, so the periodic audit is not the only unbiased look the organization ever takes. What an evaluation produces is treated as an input to improvement and not only as a conformity verdict: the findings, the observations and the opportunities each audit identifies are recorded as improvements with owners and dates and carried into the organization’s improvement process, so an audit changes something rather than closing. Where a regime names the parties an assessment result must reach, such as a regulator, a certifying body or the customers the assessed service serves, the results go to those parties as well as to the management responsible for the area audited. What an evaluation finds is carried back into the safeguards themselves and not only into a report: the measures the organization has actually implemented are reviewed as part of each evaluation and MODIFIED where they no longer provide protection that is reasonable and appropriate for the environment as it now stands, and the documentation describing those measures is updated to match whatever was changed - so the record of what is in place and the thing in place do not drift apart between one audit and the next.", "crosswalks": { "fedramp-rev5-class-c": [ "CA-2(3)", "CA-1", "CA-2", "CA-2(1)", "CA-7(1)" ], "fedramp-rev5-class-d": [ "CA-2(2)", "CA-2(3)", "CA-1", "CA-2", "CA-2(1)", "CA-7(1)" ], "nist-csf": [ "ID.IM-01" ], "iso-9001": [ "9.2.1", "9.2.2" ], "soc-2": [ "CC4.1" ], "iso-27001": [ "9.2", "A.5.35" ], "iso-42001": [ "9.2" ], "hipaa": [ "164.306(e)", "164.308(a)(8)" ], "nist-800-171": [ "3.12.1" ], "nist-800-53": [ "CA-1", "CA-2", "CA-2(1)", "CA-7(1)" ], "coppa": [ "312.8(b)(5)" ], "sox": [ "P16" ], "fedramp-rev5-class-b": [ "CA-1", "CA-2", "CA-2(1)" ] } }, { "key": "management-review", "name": "Management review", "description": "Leadership reviews how the management system is performing at planned intervals and decides what to do about it: what will be improved, and what about the system itself has to change. Each decision leaves the review with a named owner and a date rather than as a sentiment in the minutes, the previous review’s decisions are picked back up at the next one so nothing is decided twice and never done, and the record of the review and its outputs is retained. The risk management strategy is one of the review’s standing subjects: what the strategy actually produced is reviewed for what it says about the direction being taken, and the strategy itself is then reviewed and adjusted for whether it still covers the requirements the organization is under and the risks on its register - so a strategy the year has overtaken is changed at the review rather than reaffirmed by it. The review is planned rather than convened, and what it has to consider is fixed in advance: the status of actions from previous reviews; changes in the external and internal issues that bear on the system; the satisfaction of customers and the feedback of other interested parties; how far the objectives set for the system have been met; how the processes are performing and whether what the organization delivers conforms; the nonconformities raised and the corrective actions taken; the results of monitoring and measurement; audit results; how external providers are performing; whether the resources the system has are adequate; the effectiveness of the actions taken on risks and opportunities; and the opportunities for improvement on the table. An input that is missing on the day is recorded as missing rather than passed over, so the review is answerable for what it did not see as well as for what it decided. Where the organization develops or uses AI, the AI governance program is a standing subject of the same review rather than a separate forum: what the AI systems in scope did, what the risks and impacts recorded against them showed, and what should change - taken with the rest of the agenda by the same leadership, so an AI decision is weighed against the organization’s other commitments instead of beside them.", "crosswalks": { "nist-csf": [ "GV.OV-01", "GV.OV-02" ], "iso-27001": [ "9.3" ], "iso-9001": [ "9.3.1", "9.3.2", "9.3.3" ], "soc-2": [ "CC4.1" ], "esg-essentials": [ "G.14" ], "sox": [ "P16" ], "iso-42001": [ "9.3" ], "ai-governance-essentials": [ "GV.5" ] } }, { "key": "nonconformity-capa", "name": "Nonconformity & corrective action (CAPA)", "description": "When something fails to meet a requirement, the first response is to contain it: the nonconforming output is controlled so it goes no further, what has already gone wrong is corrected, and the consequences of it are dealt with. Then the question of cause is asked - why it happened, and whether the same failure exists somewhere else or could happen somewhere else - and where the answer warrants action, that action is taken and tracked to closure. Each failure is rated for how serious it is and put in front of the people who actually have the authority to fix it, on a timescale set by that rating rather than by the next scheduled meeting - and where the rating warrants it, that includes senior management and the governing body. Afterwards the action is reviewed for whether it actually removed the cause rather than only for whether it was completed, the management system is changed where the review shows it has to be, and the nonconformity, what was done about it and the result of doing it are all recorded. Open findings are held in one plan of action rather than in the report each came from: a single tracked list carrying every weakness and deficiency the organization has found - from an assessment, an audit, a scan, a test, an incident or a report from outside - with the remediation intended for each, the milestones it will pass and the date it is due, updated as findings are closed and as new ones arrive rather than rebuilt at the next review.", "crosswalks": { "iso-27001": [ "10.2" ], "iso-9001": [ "8.7.1", "8.7.2", "10.2.1", "10.2.2" ], "soc-2": [ "CC4.2" ], "nist-800-171": [ "3.12.2" ], "nist-800-53": [ "CA-5" ], "sox": [ "P17" ], "iso-42001": [ "10.2" ] } }, { "key": "customer-requirements", "name": "Customer requirements & satisfaction", "description": "What the customer requires is established before the organization commits to supply it, reviewed against what the organization can actually deliver, and tracked afterwards through whether the customer says it was delivered. The requirements for a product or service are determined and stated: what the customer asks for, including what it expects of delivery and of what happens after delivery; what the organization itself considers necessary; the statutory and regulatory requirements that apply to it; and nothing claimed for it that the organization cannot meet. Communication with the customer is run as part of that rather than around it - information about what is offered, the handling of inquiries, contracts and orders including changes to them, feedback and complaints, the handling of any customer property, and the contingency arrangements that apply when they are relevant. Before committing - before accepting an order, signing a contract, or agreeing a change to one - those requirements are reviewed together with the ones the customer did not state but which the known or intended use requires, and with any contract or order requirement that differs from what was previously expressed, which is resolved rather than carried forward. Where the customer gives no documented statement of requirements, what was agreed is confirmed back to the customer before acceptance. The review leaves records: documented information on the results of the review, and on any new or changed requirement for the product or service, retained rather than reconstructed afterwards from an email thread. When requirements change after commitment, the change is carried through - the documented information describing the product or service is amended, and the people whose work depends on it are made aware - so a change agreed with the customer does not stop at the account manager. Whether the customer considers their needs and expectations to have been fulfilled is monitored rather than assumed: how that perception is obtained, monitored and reviewed is decided in advance - surveys, feedback on delivered product and service, meetings with customers, analysis of market share, compliments, warranty claims, dealer reports - and what it produces is reviewed and acted on. Top management is accountable for all of it: it requires customer requirements and the applicable statutory and regulatory requirements to be determined, understood and consistently met; it requires the risks and opportunities that could affect conformity of products and services, or the ability to enhance customer satisfaction, to be determined and addressed; and it keeps enhancing customer satisfaction as a stated aim rather than a by-product.", "crosswalks": { "iso-9001": [ "5.1.2", "8.2.2", "8.2.3.1", "8.2.3.2", "8.2.4", "9.1.2" ] } }, { "key": "organizational-context", "name": "Organizational context", "description": "The internal and external issues that bear on the management system are determined and written down: what the organization does and how it is structured, the technology and information it depends on, the people and culture inside it, and outside it the markets it sells into, the laws and contracts binding it, the threat environment it operates in and whatever else could affect whether the system achieves what it exists to achieve. Each issue is recorded with enough reasoning that a reader can see why it matters here rather than in general, and the record is revisited on a defined cadence and whenever something material changes - an acquisition, a new market, a new regulator, a new class of threat - so it is the current picture and not the one taken when the system was first set up. The mission the organization exists to carry out is stated as part of that record, in its own words rather than by implication, and the cybersecurity risk decisions taken under the management system are traced back to it - so a risk is prioritized for what it would do to the mission rather than for how alarming it sounds.", "crosswalks": { "nist-csf": [ "GV.OC-01" ], "iso-27001": [ "4.1" ], "iso-9001": [ "4.1" ], "iso-42001": [ "4.1" ] } }, { "key": "interested-parties-requirements", "name": "Interested parties & their requirements", "description": "The parties with a stake in the management system are identified - customers, regulators and supervisory authorities, employees, owners and investors, suppliers, insurers, and anyone else whose requirements bear on it - and what each of them requires is recorded specifically enough to be tested against rather than as a category. That includes the legal, regulatory and contractual obligations that follow from each relationship. The organization then records which of those requirements it will meet through the management system and which it will not, so the boundary is a decision on the record with a reason attached rather than an omission nobody noticed. The list is reviewed on a cadence, and whenever a new obligation, contract, relationship or regulator arrives. The parties inside the organization count as well as those outside it - the functions whose work the system constrains, and the people who have to operate it - and what each of them expects of the way cybersecurity risk is managed is recorded beside what it requires of the organization, and considered in the decisions taken, so an expectation that was heard is visibly carried through rather than noted and passed over.", "crosswalks": { "nist-csf": [ "GV.OC-02" ], "iso-27001": [ "4.2" ], "iso-42001": [ "4.2" ] } }, { "key": "management-system-scope", "name": "Management system scope statement", "description": "The boundaries of the management system are decided and written down as a scope statement: which parts of the organization, which locations, which activities, which information and which technology sit inside it, and what sits outside. The statement is reasoned from the issues determined about the organization’s context and from what interested parties require, rather than drawn to be convenient, and it states the interfaces and dependencies between what the organization does itself and what is done for it by others - so a boundary drawn around a service someone else runs is visible on the page instead of implied by its absence. The scope is available as documented information, and it is revisited when the organization, its activities, or those dependencies change. Those dependencies are understood and made known, not merely bounded: the outcomes, capabilities and services the organization relies on others to provide are named in the scope record along with what inside the organization depends on each, and the record is made available to the roles whose work assumes them - so a dependency is something the organization can point at rather than something it learns about when the dependency fails. The scope names the products and services it covers, not only the organizational units, because a boundary drawn around a division says nothing about which of its offerings the system is answering for. And where a requirement of the standard the system is built against is judged not to apply inside that boundary, the judgment is recorded with the reason it holds - which requirement, why it cannot affect the organization’s ability to deliver conforming products and services, and who decided - so an exclusion is an argument on the page rather than a silence in the scope.", "crosswalks": { "nist-csf": [ "GV.OC-05" ], "iso-27001": [ "4.3" ], "iso-9001": [ "4.3" ], "iso-42001": [ "4.3" ] } }, { "key": "management-system-processes", "name": "Management system processes & interactions", "description": "The management system is run as one connected set of processes rather than as a pile of separate activities that happen to share a binder. The processes it needs are identified, each with what goes into it and what comes out, the order they run in and how they hand off to one another, the criteria and methods that tell whether it is working, who owns it, and what it needs to run. The map is kept current as processes are added, merged or dropped, and it is used - improvement of the system is driven from it, and a change to one process is traced through to the processes it feeds - rather than drawn once for an audit and filed. The risks and opportunities each process carries are determined and addressed as part of defining it, so a process is designed against what could stop it delivering its intended output rather than only against how it runs when nothing goes wrong. The map is documented rather than held in someone’s head: the information needed to support the operation of the processes is maintained and kept current, and enough is retained from the running of them to give confidence they were carried out as planned - the second being a record of what happened, not a description of what should.", "crosswalks": { "iso-27001": [ "4.4" ], "iso-9001": [ "4.4.1", "4.4.2" ], "iso-42001": [ "4.4" ] } }, { "key": "leadership-commitment", "name": "Leadership commitment & accountability", "description": "Top management is accountable for whether the management system works, and the accountability is exercised rather than asserted. It approves the policy and the objectives and satisfies itself that they fit the direction the organization is actually going in; it requires the system’s requirements to be built into how the business already runs rather than bolted alongside it; it makes sure the resources the system needs are available; it tells the organization why conforming to the system matters, in its own voice; it directs and supports the people whose work makes the system effective; it promotes improvement; and it backs other managers in exercising leadership over the parts of the system that are theirs. What it decided, when, and on what basis is recorded, so the commitment is evidenced by acts rather than by a signature on a policy. Leadership is accountable for cybersecurity risk itself and not only for the system that manages it, and it fosters the culture that has to go with that: risk-aware, ethical, and expected to keep improving rather than to hold a standard once reached. It also requires cybersecurity risk management activities and their outcomes to be carried inside the organization’s enterprise risk management process - the same register, the same reporting line, the same committee that hears the other risks - rather than in a security-only record that never reaches the people who allocate capital against it. It promotes two habits by name rather than by implication: the process approach, meaning the work is understood, run and improved as connected processes with defined inputs, outputs and owners; and risk-based thinking, meaning what could go wrong is considered while the work is being planned rather than after it has gone wrong. And it satisfies itself that the system achieves the results it was set up to achieve - the intended outcomes, checked - so leadership answers for the system’s effect and not only for its existence.", "crosswalks": { "fedramp-20x": [ "KSI-PIY-RES" ], "nist-csf": [ "GV.RR-01", "GV.RM-03" ], "iso-27001": [ "5.1" ], "iso-9001": [ "5.1.1" ], "iso-42001": [ "5.1" ] } }, { "key": "security-objectives", "name": "Information security objectives & planning", "description": "Information security objectives are set at the functions and levels that actually have to deliver them, consistent with the security policy, and stated so that whether they were met can be measured rather than argued about afterwards. What they are set against is the security requirements the organization has and the results of its risk assessment and treatment, so the objectives answer the risks on the register rather than restating good intentions. Those requirements include the commitments the organization has made to its customers about the service and the system requirements those commitments create, so an objective is stated precisely enough that somebody can work out what would threaten it. Each objective carries a plan: what will be done, what resources it needs, who is responsible for it, when it is to be finished, and how the result will be evaluated. Objectives are communicated to the people whose work affects them, monitored, updated as circumstances change, and kept as documented information. The objectives for managing risk itself are set on the same terms and agreed with the stakeholders who have to deliver them and live with them, rather than issued by the security function alone - so what the organization is trying to achieve by managing cybersecurity risk is a shared position on the record and not an assumption each function makes separately.", "crosswalks": { "nist-csf": [ "GV.RM-01" ], "iso-27001": [ "6.2" ], "soc-2": [ "CC3.1" ] } }, { "key": "management-system-change-planning", "name": "Planned change to the management system", "description": "When the management system itself needs to change - its scope, its policy, its objectives, the processes it runs, the roles and authorities inside it, or the method by which it assesses risk - the change is carried out in a planned way rather than absorbed. Before it is made, its purpose and what it is likely to cause are stated; the integrity of the system while the change is in progress is considered, so it does not stop working half way through; the resources the change needs are identified and made available; and the responsibilities and authorities it moves are reallocated and communicated to the people gaining and losing them. The change, the reasoning and the approval are recorded, and afterwards the result is checked against the purpose the change was made for.", "crosswalks": { "iso-27001": [ "6.3" ], "iso-9001": [ "6.3" ], "iso-42001": [ "6.3" ] } }, { "key": "management-system-resources", "name": "Resources for the management system", "description": "The resources the management system needs in order to be established, run, kept running and improved are determined and provided, not assumed: the people and the time they are actually given rather than the time the plan says they have, the tools and technology, the information, and the budget. The determination distinguishes what the organization can meet from its own capability from what it has to obtain from outside, and it is written down so a shortfall is visible as a shortfall. It is revisited when the system’s scope, its workload or the organization changes, so a system that has grown is not still resourced for the size it was when it started. Security and privacy are budgeted as a discrete line rather than absorbed into a general technology allocation. The high-level security and privacy requirements for a system or a service are determined while the business process it serves is being planned, rather than after the design is fixed; what it will cost to protect it is then determined, documented and allocated as part of the organization’s capital planning and investment process; and that amount appears as a discrete line item in the programming and budgeting record - so an underfunded control is a visible decision rather than an unexplained gap. Adequacy is judged against the risk strategy rather than against last year’s allocation: what is provided is set commensurate with the risks the organization has said it will manage, the roles it has assigned and the policies it has issued - and where it is not, the shortfall is recorded against the part of the strategy it fails to fund. People are determined as their own class of resource rather than counted inside a budget line: the persons necessary for the system to be implemented effectively, and for its processes to be operated and controlled, are identified from the work that has to be done and are then actually provided - so a process with nobody assigned to run it is visible before it fails rather than after. Where the management system depends on data and on computing capacity - not only on people, tools and money - those are determined and provided as resource classes in their own right, so a system planned without the data it needs, or without the compute to run what it plans, is a visible shortfall rather than a later discovery.", "crosswalks": { "fedramp-20x": [ "KSI-PIY-RIS" ], "nist-csf": [ "GV.RR-03" ], "iso-27001": [ "7.1" ], "iso-9001": [ "7.1.1", "7.1.2" ], "nist-800-53": [ "SA-2" ], "iso-42001": [ "7.1" ], "fedramp-rev5-class-b": [ "SA-2" ], "fedramp-rev5-class-c": [ "SA-2" ], "fedramp-rev5-class-d": [ "SA-2" ] } }, { "key": "management-system-communication", "name": "Management system communication plan", "description": "What the management system has to communicate is decided in advance and written down rather than left to whoever remembers: on what subjects, when, to whom inside the organization, to whom outside it, by whom, and by what means. The plan covers what goes out routinely - policy changes, objectives, how the system is performing, the obligations people are under, including what each part of the organization is responsible for in operating the system - and what goes out on a trigger, and it names who is authorized to speak externally so a communication that carries an obligation is not made by whoever picked up the phone. It is reviewed when the audience, the obligations or the system change, and what was communicated, to whom and when is recorded, so the plan can be shown to have been followed rather than merely written. Cybersecurity risk has its own named lines within that plan: which risks are reported upward and to whom, how a risk raised in one part of the organization reaches the other parts it affects, and how risk arising from suppliers and other third parties enters those same lines instead of staying inside the relationship that produced it. The plan covers the incident case too, so recovery activities and the progress made in restoring operational capability are communicated to the designated internal and external stakeholders on terms set in advance rather than on whatever the responders have time for.", "crosswalks": { "nist-csf": [ "GV.RM-05", "RC.CO-03" ], "iso-27001": [ "7.4" ], "iso-9001": [ "7.4" ], "soc-2": [ "CC2.2", "CC2.3" ], "iso-42001": [ "7.4" ] } }, { "key": "operational-planning-control", "name": "Operational planning & control", "description": "The processes that deliver what the management system requires are planned before they are run and controlled while they run. The criteria each process has to meet are set in advance; the process is carried out to those criteria; and enough is recorded to give confidence afterwards that it ran as planned, rather than only that it ran. Changes to those processes are controlled: a planned change has its consequences considered before it is made, and an unintended change - something that drifted, broke or was worked around - is reviewed after the fact and acted on where it did harm. Processes, products and services provided from outside the organization but relied on inside it are brought within the same criteria and the same control, because a process that has been handed to someone else is still one the system depends on. Planning starts from what has to be true of the output: the requirements the products and services themselves must meet are determined before the processes that deliver them are designed, and the resources needed to achieve conformity to those requirements are determined alongside them - so a process is not planned to criteria it was never resourced to meet.", "crosswalks": { "iso-27001": [ "8.1" ], "iso-9001": [ "8.1" ], "iso-42001": [ "8.1" ] } }, { "key": "risk-treatment-plan", "name": "Risk treatment plan & residual risk acceptance", "description": "The treatment decisions coming out of the risk assessment are drawn together into one plan somebody can be held to: for each risk, what will be done about it, which control does it, who owns that work, and by when. The controls chosen are the ones expected to bring the risk down to the level the organization has said it will accept, they mix preventive and detective measures rather than relying on one kind, and they are placed across the business processes where the risk actually arises instead of being concentrated in whichever layer is easiest to change. The people who own the risks approve the plan and accept, in writing, the risk that will still be there once it is done - so residual risk is a decision a named person made rather than the remainder nobody looked at. The plan is then carried out; progress is tracked to closure rather than to first action; and the result of each item is recorded - what was actually implemented, and what it changed about the risk it was raised against. Above the individual plan sits a stated strategic direction on response: which kinds of response the organization considers appropriate to which kinds of risk - avoid, reduce, share, transfer or accept - established and communicated in advance, so a treatment decision is taken against a known position rather than argued from first principles each time. Each response is then chosen against that direction, prioritized against the others, planned with an owner and a date, tracked to closure, and communicated to the people whose work it changes.", "crosswalks": { "fedramp-rules-2026": [ "VER-TFR-MAV" ], "nist-csf": [ "GV.RM-04", "ID.RA-06" ], "iso-27001": [ "8.3" ], "soc-2": [ "CC5.1" ] } }, { "key": "security-performance-measurement", "name": "Security performance measurement", "description": "What the organization will monitor and measure in order to know whether information security is working is decided in advance and written down: which processes and which controls, by what method, who performs the measurement, when it is performed, and who analyzes and evaluates the results and when. The methods are chosen so that repeating them produces comparable and reproducible results, rather than a different answer depending on who ran it and in which week. The results are retained, and the evaluation - what the numbers say about whether the management system is performing and whether its controls are effective, not merely what they count - reaches the people who decide what to do about it, in time for them to do it. Measurement is set up as a CONTINUOUS strategy rather than a periodic exercise, and the strategy states its parts: the metrics to be monitored; how often each control is assessed and how often the results are monitored, with the frequencies chosen deliberately and written down; ongoing assessment of whether each control is still implemented correctly, operating as intended and producing the intended result; correlation and analysis of what monitoring produces, so separate readings are interpreted together; a response to what the analysis finds; and reporting of the organization’s security and privacy status to the roles that need it, at a stated frequency. Risk is monitored as part of the same strategy rather than beside it, on three axes: whether the treatments in place are still effective, whether the organization is still complying with the requirements it is subject to, and whether anything has changed - in the systems, the environment, the threats or the organization itself - that makes the current picture out of date. The evaluation covers how the organization is performing at MANAGING cybersecurity risk, not only how the individual controls are performing, and it is reviewed specifically for what should be adjusted as a result - so the measurement program produces a decision rather than a report.", "crosswalks": { "nist-csf": [ "GV.OV-03" ], "iso-27001": [ "9.1" ], "nist-800-171": [ "3.12.3" ], "nist-800-53": [ "CA-7", "CA-7(4)" ], "fedramp-rev5-class-b": [ "CA-7", "CA-7(4)" ], "fedramp-rev5-class-c": [ "CA-7", "CA-7(4)" ], "fedramp-rev5-class-d": [ "CA-7", "CA-7(4)" ] } }, { "key": "continual-improvement", "name": "Continual improvement", "description": "Improvement of the management system is run as an activity with a record, not held as an intention. Opportunities are captured from everywhere they arise - audit findings, the results of measurement and evaluation, decisions out of management reviews, incidents and near misses, and suggestions from the people actually doing the work - and held in one place instead of in the meeting each came out of. Each is evaluated and either taken forward with an owner and a date or closed with the reason it was not, so a rejected idea is a decision rather than a silence. Once an improvement is made, its effect on the suitability, adequacy and effectiveness of the system is checked, so improvement is something that can be shown to have happened rather than asserted at the next audit. The routine execution of the work counts as a source in its own right: what the operational processes, procedures and activities themselves show while they are being run - the step that is always skipped, the check that never fires, the manual workaround everybody has quietly adopted - is captured on the same terms as a finding from an audit, because the people running a process daily see more of it than any evaluation does. Where the thing being improved is an AI system, the improvement activity is built into the system’s own update cycle and is measurable: an update carries the improvement it is meant to deliver and the measure that will show whether it did, checked afterwards rather than asserted, and interested parties - the people who operate the system, the people it is used on, and those who represent them - are engaged regularly as part of that cycle rather than consulted once at launch. The opportunities are not confined to the system: what the organization delivers is in scope too. Improving products and services to meet known requirements and to address needs and expectations that are coming rather than current, correcting, preventing or reducing undesired effects, and improving how the system itself performs are all determined and selected against as improvement opportunities, rather than run as three unrelated programs. And the standing question - what in the system’s suitability, adequacy and effectiveness should be improved next - is answered from evidence rather than appetite: the results of analysis and evaluation and the outputs of management review are considered together to decide whether there is a need or an opportunity that has to be addressed.", "crosswalks": { "fedramp-20x": [ "KSI-SVC-EIS" ], "nist-csf": [ "ID.IM-03" ], "iso-27001": [ "10.1" ], "iso-9001": [ "10.1", "10.3" ], "nist-ai-rmf": [ "MANAGE-4.2" ], "iso-42001": [ "10.1" ] } }, { "key": "environmental-policy", "name": "Environmental policy", "description": "A written environmental policy stating the organization’s commitments, scope, and responsibilities.", "crosswalks": { "esg-essentials": [ "E.1" ] } }, { "key": "energy-emissions-tracking", "name": "Energy, emissions & resource use tracking", "description": "Regular measurement of energy consumption, an operational (Scope 1 & 2) greenhouse-gas inventory, and metering of the other material resources the business consumes, such as water. Where the organization trains, tunes or runs AI models, the environmental impact and sustainability of that work is assessed and documented on the same terms as the rest of its consumption - the energy and compute drawn by training and retraining, what serving the model in production adds on top, and where that sits against the organization’s own targets - so a footprint created by a model rather than by a building is measured rather than left as somebody else’s.", "crosswalks": { "esg-essentials": [ "E.2", "E.3", "E.5" ], "nist-ai-rmf": [ "MEASURE-2.12" ] } }, { "key": "waste-recycling", "name": "Waste & recycling program", "description": "Waste streams are tracked and recycling or diversion is implemented where practical.", "crosswalks": { "esg-essentials": [ "E.4" ] } }, { "key": "environmental-targets", "name": "Environmental reduction targets", "description": "At least one measurable environmental reduction target is set and progress is reviewed.", "crosswalks": { "esg-essentials": [ "E.6" ] } }, { "key": "health-safety", "name": "Health & safety program", "description": "A safe working environment with incident recording, review, and corrective action. Recording is not the end of it where the law says otherwise: the incidents that meet a statutory reporting threshold - a death at work, and the serious outcomes the regime names, such as an admission to hospital, an amputation or the loss of an eye - are reported to the regulator within the window that regime sets, counted from when the organization learned of the event, and someone is accountable for making that call quickly enough that the window can still be met.", "crosswalks": { "esg-essentials": [ "S.1" ], "us-employment-federal": [ "us.health-safety.general-duty", "us.health-safety.injury-recordkeeping", "us.health-safety.severe-incident-reporting" ] } }, { "key": "dei-commitment", "name": "Diversity, equity & inclusion commitment", "description": "A DEI commitment with representation tracked where lawful and appropriate.", "crosswalks": { "esg-essentials": [ "S.2" ] } }, { "key": "fair-labor-practices", "name": "Fair labor practices", "description": "Compliance with wage, hour, and anti-discrimination obligations for all workers.", "crosswalks": { "esg-essentials": [ "S.3", "S.13" ], "us-employment-federal": [ "us.wage-hour.minimum-wage", "us.wage-hour.overtime", "us.wage-hour.child-labor", "us.pay-equity.equal-pay-act", "us.pay-equity.title-vii-compensation" ] } }, { "key": "individual-privacy", "name": "Personal data privacy", "description": "A privacy notice the organization owns and dates tells the people whose personal data it holds - employees, customers, and anybody else it collects from - what is collected and where from, the purposes it is used for, how long it is kept, who it is disclosed to, what choices and rights they have and how to exercise them, and how employees are monitored at work. It is written in plain language, published where those people will find it, and revised and made available BEFORE a change in practice takes effect rather than after. Each request about that data - to see it or get a copy, to have it corrected, to have it erased, to restrict or object to a use - is logged when it arrives, the requester’s identity is checked, and it is decided and actioned inside the time the organization has committed to; what is provided is what was asked for, and a refusal is given with its reason rather than by silence. An accepted correction is applied to every copy the organization holds and passed on to the parties it has already disclosed that data to, so a correction does not stop at whichever system the request happened to arrive in.", "crosswalks": { "esg-essentials": [ "S.8" ], "iso-27001": [ "A.5.34" ], "gdpr": [ "Art.12(1)", "Art.12(2)", "Art.15(1)", "Art.16", "Art.17(1)", "Art.21(1)" ], "soc-2": [ "P1.1", "P5.1", "P5.2" ], "pipeda": [ "4.2", "4.2.3" ] } }, { "key": "records-of-processing", "name": "Record of processing activities (RoPA)", "description": "A register of every activity in which the organization processes personal data, kept current as processing changes rather than assembled for an audit — each entry recording the purpose, the lawful basis relied on, the categories of individuals and of personal data, who the data is disclosed to, how long it is kept, any transfer outside the region with the safeguards relied on, and the security measures protecting it. The register is kept in writing, electronic form included, so it is a record that can be produced rather than knowledge held by whoever has been here longest.", "crosswalks": { "gdpr": [ "Art.30(1)", "Art.30(3)" ], "pipeda": [ "4.2.1", "4.5.1" ] } }, { "key": "dpia-process", "name": "Data protection impact assessment (DPIA) process", "description": "Before a new processing activity begins — and before an existing one changes in a way that alters the risk it poses — it is screened for whether it is likely to result in a high risk to people, and where it is, an impact assessment of that specific processing is completed before the processing starts: describing the processing and its purposes, testing its necessity and proportionality against them, assessing the risks to the people affected, and setting out the measures, safeguards and security mechanisms that address those risks. The screen always returns a requirement, whatever else it weighs, in three cases: a systematic and extensive evaluation of personal aspects carried out by automated processing, profiling included, on which decisions are based that produce legal effects for the people concerned or similarly significantly affect them; processing on a large scale of the categories of data that carry extra protection, or of data about criminal convictions and offenses; and systematic monitoring of a publicly accessible area on a large scale. Where a data protection officer has been designated, their advice is sought while the assessment is being carried out, and what they advised is recorded alongside it rather than absorbed into the conclusion. Where it is appropriate to do so, the views of the people the processing affects, or of their representatives, are sought on what is intended - and where they are not sought, the reason is recorded, so “not appropriate” is a decision rather than a default; commercial and public interests and the security of the processing itself are protected in how that is done. The assessment does not end when it is signed: where necessary, and at least whenever the risk the processing presents changes, a review checks that the processing is actually being carried out in the way the assessment said it would be, which is a different question from whether the activity needs re-screening, and the outcome of that check is recorded. Where the processing is carried out by an AI system, the privacy risk the system itself creates is examined and documented as part of the same work, not only the privacy risk of the data going into it: what a trained model can memorize and later reveal, what can be re-identified or inferred about a person from its outputs even where no record of them is stored, and what the people whose data was used to build it are exposed to by its continuing to run.", "crosswalks": { "gdpr": [ "Art.35(1)", "Art.35(2)", "Art.35(3)", "Art.35(7)", "Art.35(9)", "Art.35(11)" ], "nist-ai-rmf": [ "MEASURE-2.10" ] } }, { "key": "breach-notification", "name": "Breach assessment & notification", "description": "A standing procedure for a suspected compromise of protected health information. It decides against documented criteria whether the incident is notifiable, and then issues each notice that decision requires - without unreasonable delay and in no case later than 60 calendar days, counted from the day the incident was discovered rather than the day it was understood. To the affected individuals: in plain language, what happened and when, what data was involved, what those people should do to protect themselves, what the organization is doing to investigate it, mitigate harm and protect against further breaches, and how to ask questions or learn more - the last given as contact procedures that MUST include a toll-free telephone number, an e-mail address, a website or a postal address, not merely an invitation to get in touch - sent by first-class mail to the last known address, or by email where the person has agreed to electronic notice and has not withdrawn that agreement, or, where the individual is known to have died and an address is held, to the next of kin or personal representative. Where contact details are missing or stale, substitute notice is given: by another written form, telephone or other means for fewer than ten such individuals; for ten or more, by a conspicuous posting on the home page of the organization’s website for 90 days or a conspicuous notice in major print or broadcast media where those affected likely live, with a toll-free number that stays active for at least 90 days. To prominent media serving a State or jurisdiction, on the same clock and carrying the same content, when the breach involves more than 500 residents of it. To the regulator on its own clock and in the form the regulator specifies: at the same time as the individual notices where 500 or more individuals are involved, and for breaches involving fewer than 500 through a maintained log filed no later than 60 days after the end of each calendar year, covering the breaches discovered in it. Where the organization holds the data on another organization’s behalf, the notice goes to that organization instead, identifying every individual affected and everything it needs for its own notifications. A notification, notice or posting is delayed only where a law-enforcement official states it would impede an investigation or damage national security - for the period a written statement specifies, or, where the statement is spoken, for no longer than 30 days from the date it was made, with the statement and the identity of the official who made it written down at the time and the delay ending sooner if no written statement follows. The procedure is issued as policy, the people who operate it are trained on it, complaints about it are handled, failures to follow it are sanctioned like any other policy breach, nobody is penalized for raising one, and nobody is required to give up a right in order to receive treatment, payment, enrollment or benefits. Every determination and every notice - its content, its recipients, the method and the date - is retained for six years from creation or from when it last was in effect, whichever is later, so the organization can show either that it notified as required or that the incident was not notifiable.", "crosswalks": { "hipaa": [ "164.404(b)", "164.404(c)", "164.404(d)", "164.406(b)", "164.406(c)", "164.408(b)", "164.408(c)", "164.410(b)", "164.410(c)", "164.412", "164.414(a)", "164.414(b)" ] } }, { "key": "privacy-notice", "name": "Privacy notice & transparency", "description": "A privacy notice the organization owns, versions and dates, written in plain language and carrying the content it is required to carry: a prominent statement of what the notice is for, how personal data is used and disclosed with examples, what rights the individual has and how to exercise them, what the organization is obliged to do, a statement that the individual may complain both TO THE ORGANIZATION AND TO THE SECRETARY of Health and Human Services, with a brief description of how to complain to the organization and an assurance that nobody is retaliated against for doing so, the name or title and telephone number of a contact person or office, and the date it takes effect. It is available on request to anyone who asks, and it reaches the individual by the route their relationship with the organization sets: a health plan gives it at enrollment and tells those it covers where to get it at least once every three years; a provider treating people directly gives it no later than the first time it delivers a service - not before data is collected, which is a different and later trigger than a consent-first regime uses - or as soon as practicable after an emergency, and makes a good-faith effort to get a written acknowledgement of receipt, recording the attempt where none is obtained. Where the organization runs a website describing its services or benefits, the notice is posted prominently on it; where it has a physical site people come to, a copy is kept there for individuals to take away and the notice is posted in a clear and prominent place where someone waiting to be seen can read it. Where a notice is issued jointly with other organizations, each of them agrees to abide by its terms, and the notice describes with reasonable specificity both the organizations (or classes of organization) and the SERVICE DELIVERY SITES (or classes of site) it applies to, and says, where it is so, that those organizations WILL SHARE the individual’s data with each other to carry out the work the arrangement exists for - so a reader learns from the notice which premises they are covered at and that their data moves between the participants. Issue by any one participant discharges the duty for all of them. A copy of every version issued is retained, along with any acknowledgement of receipt and, where one could not be obtained, the record of the good-faith attempt. When a practice the notice describes changes, the notice is revised and made available before the change takes effect - not after it. The notice binds practice rather than describing it: personal data is not used or disclosed in any manner INCONSISTENT with the notice currently in effect, so the notice is a limit on what the organization may do and not a summary of what it happens to do. And where the notice was required to carry a specific statement before the organization could engage in a particular activity - contacting people to raise funds, a group health plan disclosing to its plan sponsor, or a health plan underwriting - that activity is not carried on AT ALL unless the statement is actually in the notice. Which is why the order runs one way only: the notice is revised first and the practice follows it.", "crosswalks": { "hipaa": [ "164.502(i)", "164.520(b)", "164.520(c)", "164.520(d)", "164.520(e)", "164.530(i)(4)" ], "pipeda": [ "4.8", "4.8.1", "4.8.2", "4.8.3" ] } }, { "key": "individual-rights-requests", "name": "Individual rights request handling", "description": "Every request an individual makes about their own personal data - to see it or get a copy, to have it corrected or amended, to restrict how it is used or disclosed, or to be contacted only by a particular means or at a particular address - is logged when it arrives, the requester’s identity is checked, and the request is answered inside the window that right carries - 30 days for a request to see or copy, 60 days for a request to amend - with at most one 30-day extension, and only if the individual is told in writing why and by when. What is provided is what was asked for - INSPECTION, a copy, or both - in the form and format asked for where that is readily producible, arranging with the individual a convenient time and place to inspect or collect it, or mailing it where they ask; transmitted to a third party where the individual directs it in a signed writing naming that person and where to send it; and charged at no more than a reasonable cost-based fee. A refusal is given in writing in plain language with the reason; anything else that was asked for and is not refused is still provided; where the organization does not hold the data at all and knows who does, it tells the individual where to send the request instead of simply refusing; and the individual is told what to do next - review by a LICENSED HEALTH CARE PROFESSIONAL whom the organization designates and who took no part in the original decision, where that route exists, or the right to file a statement of disagreement with the record - and how to complain BOTH to the organization and to the Secretary of Health and Human Services, with the name or title and telephone number of the contact person or office to use. An accepted correction is made by identifying the records it affects and APPENDING the correction, or a link to where it lives, to them - the original entry stays and the record is added to, because a record that is silently overwritten loses the history a later reader needs and destroys the evidence of what was relied on at the time; the individual is told the correction was accepted and asked to identify, and agree to, the people it should be shared with, and those people are then notified along with anyone known to hold the data who may rely on it to the individual’s detriment; a correction notified to the organization by another organization is applied to its own copy the same way, by appending rather than replacing. Where a correction is refused, the individual may file a statement of disagreement; the organization may write a rebuttal and gives the individual a copy of it when it does; and the request, the refusal, the statement and any rebuttal are appended or linked to the record and travel with it - or an accurate summary does - on any later disclosure of the data they concern. An agreed restriction or an agreed alternative contact arrangement is recorded, and it ends only where the individual agrees to or asks for the ending IN WRITING, where they agree ORALLY AND THAT ORAL AGREEMENT IS WRITTEN DOWN, or by the organization telling the individual it is ending the agreement - and that last, one-sided route does not work AT ALL against a restriction the organization had no choice but to accept - the restriction on disclosing to a health plan an item or service the individual paid for in full out of pocket - and otherwise takes effect only for data created or received after the individual has been told; a request for alternative contact may be required in writing but never conditioned on the individual explaining why they are asking, and may otherwise be conditioned only on being told how any payment will be handled and on being given a workable alternative address or contact method. The organization records which sets of records these requests reach and which roles receive and process them, retains the request records for six years from creation or from when they last were in effect, whichever is later, penalizes nobody - inside or outside the organization - for making a request, complaining, or taking part in an investigation, and requires nobody to give up any of these rights as a condition of getting a service, a payment or a benefit. Some of these disclosures are not the organization’s to decide. Where a right of access, or a right to an accounting of disclosures, is properly exercised, handing the information over is REQUIRED rather than permitted, so the only question the process asks is whether the request is valid and not whether the organization would rather not answer it; and where the regulator asks for records in order to determine whether the organization is complying with the rules that bind it, those records are produced, by a route written into the process in advance rather than improvised on the day the letter arrives. Where the organization is a business associate, it is REQUIRED to make two disclosures of its own: to the Secretary of Health and Human Services, when the Secretary requires it under 45 CFR Part 160, subpart C, to investigate or determine the business associate’s own compliance; and to the covered entity, the individual or the individual’s designee, as necessary for the covered entity to meet its obligations when an individual asks for an ELECTRONIC copy of their protected health information, so an access request is not stalled because the data sits in the business associate’s systems. An organization that is not a business associate has nothing to do under that sentence. Who may exercise a right on somebody else’s behalf is decided by a written rule rather than by whoever happens to be on the phone. A person who has authority under applicable law to make health care decisions for an adult or an emancipated minor is treated as that individual for the data relevant to the representation, and so is an executor, administrator or other person with authority to act for someone who has died or for their estate. The unemancipated minor is the hardest case and it is set out rather than left to judgement: a parent, guardian or person acting in loco parentis is normally the representative, EXCEPT where the minor consented to the service and no other consent was required by law and the minor has not asked for that person to be treated as the representative; where the minor could lawfully obtain the service without that person’s consent and the consent relied on came from the minor, a court or another person authorized by law; or where that person assented to an agreement of confidentiality between the minor and the provider. In each of those three the minor acts as the individual. State or other applicable law overrides all of it in both directions - where such a law permits or requires disclosure to a parent, guardian or person in loco parentis it is made, and where such a law prohibits it, it is not - and where that person is not the representative and no law addresses access at all, access is granted or refused only on the decision of a LICENSED HEALTH CARE PROFESSIONAL exercising professional judgment and only consistently with applicable law. Whichever way it goes, the determination is recorded against the request, because treating the wrong person as a representative is a disclosure to a stranger. An accommodation once agreed governs the act of COMMUNICATING and not merely the record of the agreement: every later communication of that person’s data goes by the means and to the address that was agreed, so a message sent down the ordinary channel to somebody who asked for a different one is a breach of the rule rather than a service failure, and the arrangement therefore travels with the record into every system that might contact them. Identity and authority are checked before anything is released, and what that check may rest on is written down rather than left to the person answering. Where a regime conditions a disclosure on particular documentation, statements or representations from the requester, the organization may rely on documentation that ON ITS FACE meets those requirements, where relying on it is reasonable in the circumstances. A requester who is a public official, or acting for one, is identified by an agency identification badge, other official credentials or other proof of government status where the request is made in person; by the request being on appropriate government letterhead where it is in writing; and, for a person acting on an official’s behalf, by a written statement on that letterhead or other evidence of the agency relationship such as a contract for services, a memorandum of understanding or a purchase order. AUTHORITY is verified separately from identity, by a written statement of the legal authority relied on - or an oral statement where a writing would be impracticable - and legal process issued by a grand jury or by a judicial or administrative tribunal is PRESUMED to carry that authority on its own. Where a regime allows the verification requirement to be met instead by the exercise of professional judgment, or by a good-faith belief in the narrow circumstances it names, that route is recorded as the basis for the release rather than left unstated.", "crosswalks": { "hipaa": [ "164.502(a)(2)", "164.502(a)(4)", "164.502(g)(2)", "164.502(g)(3)", "164.502(g)(4)", "164.502(h)", "164.514(h)(2)", "164.522(a)(2)", "164.522(a)(3)", "164.522(b)(2)", "164.524(b)", "164.524(c)", "164.524(d)", "164.524(e)", "164.526(b)", "164.526(c)", "164.526(d)", "164.526(e)", "164.526(f)", "164.530(g)", "164.530(h)" ], "pipeda": [ "4.9", "4.9.2", "4.9.5", "4.9.6", "8(1)", "8(2)" ] } }, { "key": "disclosure-accounting", "name": "Record & accounting of disclosures", "description": "A record is kept of the disclosures of an individual’s personal data made to other parties, each entry carrying the date, who received it and where they are if that is known, a short description of what was disclosed, and the purpose - or, where a written request prompted it, a copy of that request. On request, the individual is given an account of those disclosures covering the six years before the request, within 60 days and with at most one 30-day extension on written notice, and the first account asked for in any twelve-month period is provided without charge. A reasonable cost-based fee may be charged for a further account asked for by the same individual inside that twelve-month period only if the individual is TOLD THE FEE IN ADVANCE and is given the chance to WITHDRAW OR NARROW the request to avoid or reduce it - the fee is disclosed before the work is done, never billed after it. The organization records what an account has to contain, keeps a copy of each account it has provided, and records which roles receive and process these requests.", "crosswalks": { "hipaa": [ "164.528(b)", "164.528(c)", "164.528(d)" ], "pipeda": [ "4.9.1", "4.9.3" ] } }, { "key": "esg-oversight", "name": "ESG leadership oversight", "description": "Leadership accountability for the ESG program with periodic review of performance.", "crosswalks": { "esg-essentials": [ "G.1" ] } }, { "key": "code-of-conduct", "name": "Code of business conduct", "description": "Standards of conduct are set by the governing body and by management and written into a code the workforce - and, where the relationship warrants it, contractors and agents - is required to follow: how people are expected to behave, what a conflict of interest is and what to do when one arises, and what is simply not done here. Everyone covered acknowledges the code when they join and again when it changes, so nobody can say they were never told. Adherence is evaluated rather than assumed - through the ordinary performance cycle and through the channels people use to raise a concern - and a departure from the code is acted on promptly and proportionately by a named role, with what was decided and what was done recorded. The code itself is reviewed as the organization and the obligations on it change.", "crosswalks": { "esg-essentials": [ "G.2", "G.4" ], "soc-2": [ "CC1.1" ], "sox": [ "P1" ] } }, { "key": "anti-bribery", "name": "Anti-corruption & bribery", "description": "Bribery and facilitation payments are prohibited, with training for relevant staff.", "crosswalks": { "esg-essentials": [ "G.3" ], "sox": [ "P1" ] } }, { "key": "whistleblower-channel", "name": "Whistleblower channel", "description": "A route for reporting misconduct that does not run through the person’s own manager: a channel - more than one where the organization can support it - open to the workforce and, where they are affected by it, to people outside the organization, which accepts a report confidentially and, where the law allows, anonymously. Where reports go and who reviews them is stated, that reviewer sits outside the line management a report may concern, and there is a route to the governing body for a report that concerns management itself. Every report is logged, assessed, and either acted on or closed with a reason, and the person who raised it is told what became of it so far as confidentiality permits. Retaliation against somebody who reports in good faith is prohibited in writing and treated as misconduct in its own right. The channel is publicized often enough that the workforce can name it, because a channel nobody can name is not a channel.", "crosswalks": { "esg-essentials": [ "G.5" ], "soc-2": [ "CC2.2" ], "sox": [ "P14" ], "pipeda": [ "27.1(1)" ] } }, { "key": "delegation-of-authority", "name": "Delegation of authority & segregation of duties", "description": "Approval authority and spending limits are defined, assigned to named roles, reviewed as the organization changes, and enforced in the systems that execute transactions - so no one person can initiate, approve, record and reconcile the same transaction. The same separation is applied wherever a single person could otherwise complete a sensitive act and conceal it, not only on the financial path: the duties and areas of responsibility that must not sit together are identified and written down - requesting access and approving it, administering a system and reviewing its own logs, writing a change and releasing it to production, holding key material and authorizing its use, running a payment and reconciling it - and the system access authorizations granted to each role are defined to support that separation rather than allowed to collide, so the split is enforced by what the accounts can do and not only by what the policy says. Where the organization is genuinely too small to separate a pair of duties, that is recorded as a decision with the compensating oversight that stands in for it - an independent review of the activity after the fact, by somebody who could not have performed it - and the oversight is actually carried out rather than named.", "crosswalks": { "iso-27001": [ "A.5.3" ], "soc-2": [ "CC1.3" ], "nist-800-171": [ "3.1.4" ], "nist-800-53": [ "AC-5" ], "sox": [ "P3", "P5", "P10" ], "fedramp-rev5-class-c": [ "AC-5" ], "fedramp-rev5-class-d": [ "AC-5" ] } }, { "key": "fraud-risk-assessment", "name": "Fraud risk assessment", "description": "A periodic assessment of how fraud could occur here - fraudulent reporting, misappropriation, corruption, and management override of controls - naming the specific schemes considered and the control responding to each.", "crosswalks": { "soc-2": [ "CC3.3" ], "sox": [ "P8" ] } }, { "key": "information-completeness-accuracy", "name": "Completeness & accuracy of information used by controls", "description": "Every report, extract, query result, spreadsheet, system-generated listing and third-party statement that a control depends on is identified and listed, and for each one the organization can show why it may be relied upon rather than asserting that it came out of a system. Recorded with the output, not remembered: where the data came from, the parameters, filters and date range that produced it, who produced it and when. Established rather than assumed: that it is COMPLETE, so nothing that belongs in it is missing, and ACCURATE, so what is in it is right - by reconciliation to an independent source, by agreeing a record count or a total back to it, by reperformance of the extract, or by another check stated in advance and evidenced when performed. Information obtained from outside the organization carries the same burden as information it produced itself; its origin is not the reason to trust it. The information reaches the person who has to act on it early enough to be acted on, since data that arrives after the decision it was meant to inform is unusable however accurate it is. The output and the evidence of its check are retained together so the same conclusion can be re-reached later by someone who was not there, and when the underlying system, query or report definition changes, the basis for relying on it is established again rather than carried over.", "crosswalks": { "soc-2": [ "CC2.1" ], "sox": [ "P13" ] } }, { "key": "governing-body-oversight", "name": "Governing body oversight of internal control", "description": "A governing body - a board, an audit committee, or the equivalent body where no board exists - is identified in writing, along with what it is responsible for overseeing: the objectives the organization has set, the controls protecting them, and management’s own performance against both. Its membership is assessed for the expertise the oversight actually needs and for independence from the management it oversees, so a challenge to management can come from someone whose position does not depend on the answer; where a member is not independent, that is recorded rather than left to be assumed. The body meets on a stated cadence and receives what it needs to form its own view rather than to ratify someone else’s - the risk picture, incidents, audit findings, control deficiencies, and the state of remediation - and it is able to ask for more. Its decisions, the challenges it made, and the follow-up items it raised are minuted and tracked to closure, so oversight can be shown to have been exercised rather than merely constituted. Where the organization reports on internal control over financial reporting, the expertise the oversight needs includes financial reporting itself - enough of it, held between the members, to challenge what management has prepared - and where the organization has to disclose whether that expertise is present on the committee, that determination is reached and recorded rather than left open. The body carrying this oversight at a US public company is the audit committee, and it holds duties directly rather than through management: it is responsible for appointing the audit firm, setting its pay and overseeing its work, and the firm reports to the committee rather than to the executives whose statements it is auditing; disagreements between management and the auditor about financial reporting are resolved by the committee; each member sits on the board, takes no consulting, advisory or other compensatory fee from the organization outside that service, and is not an affiliated person of it; the committee establishes the procedures by which complaints about accounting, internal accounting controls or auditing reach it, including confidential and anonymous submissions from employees; and it may engage its own counsel and advisers, which the organization funds at the level the committee determines. Ineffective oversight here is not a soft finding - it is treated as a deficiency in its own right and remediated on the same terms as any other.", "crosswalks": { "soc-2": [ "CC1.2" ], "sox": [ "P2" ] } }, { "key": "control-accountability", "name": "Accountability for control responsibilities", "description": "Everyone who holds a control responsibility is told what it is - which control, what they have to do, and to what standard - and is held to it. Responsibilities are written into role descriptions rather than inferred from job titles, and who holds which one is kept current as people join, move and leave. Performance against them is evaluated on the same cycle as the rest of a person’s performance, and the result carries consequences in both directions: discharging a control responsibility well is recognized, and failing to discharge it is acted on by a named role rather than noted. Incentives, targets and deadlines are reviewed for the pressure they create, because a target that can only be met by working around a control is a control weakness stated as a goal - and where that pressure is found, the target is changed rather than the control. The evaluations, the recognition and the action taken are recorded. Management does not stop at the people who hold a named control: it requires everyone doing work for the organization to apply information security in the way the established policy set, the topic-specific policies and the procedures underneath them say it is to be applied. That requirement is put to people by their own manager rather than delegated to the security function, it is made before access is given rather than after a mistake, and it comes with the means to comply - the briefing, the tooling, the time, and a stated place to get guidance when a rule and the work appear to conflict. What each role is told covers its AUTHORITY as well as its duty - what it may decide on its own, what it must escalate, and to whom - so a responsibility carrying no authority to discharge it is visible as a gap rather than discovered at the moment somebody needs a decision.", "crosswalks": { "nist-csf": [ "GV.RR-02" ], "iso-27001": [ "A.5.4" ], "soc-2": [ "CC1.5" ] } }, { "key": "technology-general-controls", "name": "General controls over technology", "description": "The organization works out which of its business processes depend on technology to run correctly - which system performs the step, which one holds the record, which one moves the data between them - and then puts general controls underneath that technology rather than only around the process on top of it. Three areas are covered and named rather than left implied: the infrastructure the processes run on, so it is operated, patched, backed up and monitored to a stated standard; the security administration of that infrastructure, so administrative access is granted, reviewed and removed deliberately and privileged action is traceable to a person; and the acquisition, development and maintenance of the technology itself, so anything bought, built or changed follows a defined path before it reaches production. The dependency map and the controls answering it are revisited when a process is redesigned or a system replaced, so a control is not left pointed at technology the process no longer uses.", "crosswalks": { "soc-2": [ "CC5.2" ] } }, { "key": "capacity-management", "name": "Capacity management", "description": "How much of each system component is actually in use - compute, memory, storage, database connections, network throughput, licenses, queue depth - is measured continuously rather than inspected after a slowdown, and each measurement is held against the level at which that component stops meeting the commitments made for it. Demand is projected forward from that history and from what the business already knows is coming - a launch, a migration, a seasonal peak, a large customer - so the question being answered is when headroom runs out rather than whether it has. Thresholds are set below the failure point and alert somebody who can act on them; adding capacity is treated as a planned change with the lead time it really needs; and where capacity cannot be added quickly enough, what will be shed, throttled or queued is decided in advance rather than during the incident. Afterwards the projection is compared with what actually happened and the model corrected.", "crosswalks": { "fedramp-rev5-class-d": [ "CP-2(2)" ], "nist-csf": [ "PR.IR-04" ], "iso-27001": [ "A.8.6" ], "soc-2": [ "A1.1" ] } }, { "key": "processing-specifications", "name": "Processing specifications & data definitions", "description": "What the system is meant to process, and to what standard, is written down and kept current: the data it accepts and what each field means, the rules it applies, the outputs it produces, and the timing it commits to. Those definitions live in one place that both the people operating the system and the people relying on its output work from, so a disagreement about whether a result is right is settled against a stated specification rather than against two recollections. The parts customers and users need in order to use the service correctly are made available to them rather than held internally. A specification changes through the same controlled path as the system it describes, and each version is dated and retained, so it is possible to say afterwards which specification a given period’s processing was performed against.", "crosswalks": { "soc-2": [ "PI1.1" ] } }, { "key": "processing-input-controls", "name": "Controls over system inputs", "description": "Data entering the system is checked where it arrives rather than after it has been processed. Every input route - a form, a file, an interface, a manual entry - has stated rules for what it will accept: which fields must be present, the format and range each must fall in, and the reference data a value has to match. Completeness is established rather than assumed, by agreeing a record count, a control total or a batch header back against the sender, so a file that arrives half-written is detected as short instead of processed as small. Where an input carries an instruction, the authority of the source is checked as part of intake, so the system acts only on instructions from a party entitled to give them. Anything that fails a check is rejected or held in a queue somebody owns, with the reason recorded and a route back to the sender to correct and resubmit - nothing is silently dropped, and nothing is silently defaulted to a value the sender did not provide.", "crosswalks": { "soc-2": [ "PI1.2" ] } }, { "key": "processing-integrity-controls", "name": "Controls over system processing", "description": "Processing runs to the specification the system published, and the organization can show that it did. Each item is processed once and once only, in the sequence the specification requires, against the rules and reference data in force at the time; a duplicate is detected and rejected rather than reconciled out later. Completeness is proved through the run rather than at the end of it, by carrying counts and control totals from intake through each stage and agreeing them at the boundaries, so an item lost between two steps surfaces at the step that lost it instead of at the customer. Processing acts only on authorized instructions, and a change to a processing rule takes effect through the change process rather than through an edit to a running job. Whatever the run could not process is written to an exception queue with the reason, an owner and a deadline; exceptions are worked and cleared rather than allowed to age; and a restart after a failure resumes from a known point rather than reprocessing or skipping work.", "crosswalks": { "soc-2": [ "PI1.3" ] } }, { "key": "processing-output-controls", "name": "Controls over output and delivery", "description": "Output reaches the people entitled to it, in the form and on the timetable the specification states, and the organization can show that what arrived is what was produced. Recipients and delivery routes are defined in advance rather than added ad hoc, and output carrying confidential or personal data is protected in transit and released only to the recipient it was prepared for. Delivery is confirmed rather than assumed - by acknowledgement, by a transmission log, or by agreeing a record count or total with the recipient - and a failed or partial delivery raises an alert to somebody who resends it, instead of being discovered by the recipient. Output that is late against the committed timetable is recorded as late and the recipient is told. Distribution lists are reviewed on a stated cadence, so output does not keep flowing to somebody who is no longer entitled to receive it.", "crosswalks": { "soc-2": [ "PI1.4" ] } }, { "key": "processing-storage-integrity", "name": "Storage of inputs, work in progress and outputs", "description": "Data is stored completely and accurately at every stage it passes through - as received, while it is part-processed, and once it is finished - so a run can be reconstructed afterwards rather than only its result inspected. Where each stage is held, for how long, and who may reach it are decided in advance and kept consistent with the retention policy rather than with whatever the storage tier happens to do. Stored data is protected against loss and against undetected alteration: it is backed up, and it is checked back against the stage before it by count, total, checksum or reconciliation, with a failed check raising an alert to somebody who investigates it. Retrieval is exercised rather than assumed - data is confirmed to come back intact, in a usable form, inside the time the service commits to - and an item that cannot be retrieved or will not reconcile is treated as an exception with an owner rather than as an anomaly.", "crosswalks": { "soc-2": [ "PI1.5" ] } }, { "key": "privacy-choice-consent", "name": "Choice & consent for personal information", "description": "Before personal information is collected, the person it is about is told what choices they have over it - what they may decline, what they can turn off later, and what declining will mean for the service they receive - in words that state the consequence rather than implying it. The choice is captured as a positive act and recorded together with what was presented, when, and by which route, so the organization can show later what a person actually agreed to rather than what today’s form says. Where the information is of a kind that needs explicit agreement, that agreement is asked for separately and obtained before the collection happens, not bundled into a general acceptance of terms. Where agreement is sought inside a written declaration that also covers other matters - terms of service, an employment contract, an order form - the request for it is presented so that it clearly stands out from the rest, in a form that is intelligible and easy to get at, in clear and plain language, rather than reading as one clause among many. Agreement is asked for only where the person is genuinely free to refuse: the organization does not make a service or a contract conditional on agreeing to processing that the service or contract does not actually need, and where it depends on agreement it can say what it is needed for. Before the person agrees, they are told that they may take the agreement back at any time and that doing so does not make what was already done unlawful. A person can change or withdraw a choice by a route no harder than the one that gave it; the change takes effect in the systems that act on it rather than only in the record of it; and the record is added to rather than overwritten, so the history of what was agreed survives.", "crosswalks": { "soc-2": [ "P2.1", "P3.2" ], "gdpr": [ "Art.7(1)", "Art.7(2)", "Art.7(3)", "Art.7(4)" ], "pipeda": [ "4.3", "4.3.1", "4.3.3", "4.3.5", "4.3.6", "4.3.7", "4.3.8", "6.1" ] } }, { "key": "personal-data-collection-limitation", "name": "Collection limited to disclosed purposes", "description": "What personal information is collected is decided against the purposes the organization has disclosed, and every field collected is tied to one of them; a field nobody can tie to a purpose is not collected. All the routes information actually arrives by are inventoried - forms, interfaces, imports, third-party sources, and the data generated as a by-product of somebody using the service - so what is gathered is known rather than inferred from the form design. Collection is by lawful and fair means: the person knows it is happening, and a route that works only because they do not notice it is not used. Where information comes from a third party, the organization establishes what that party was actually permitted to pass on before relying on it. The inventory is revisited when a purpose changes or a feature is added, and when a purpose ends the collection that served it stops.", "crosswalks": { "soc-2": [ "P3.1" ], "pipeda": [ "4.4", "4.4.1", "4.2.2", "4.4.2" ] } }, { "key": "personal-data-use-limitation", "name": "Use limited to disclosed purposes", "description": "Personal information is used only for the purposes that were disclosed and agreed to, and the limit is enforced where the use happens rather than stated only in a policy: datasets and systems carry the purpose the data was collected for, and a new use is checked against it before it begins. A use outside those purposes - a new analysis, a new feature, a new audience, training a model, a secondary use by another team - is treated as a change that requires either a fresh disclosure and a fresh choice, or a recorded decision that it is compatible with the original purpose together with the reasoning for that. Where the new purpose rests on neither a fresh consent nor a law that provides for it, the compatibility decision is made against stated factors rather than asserted: any link between the purpose the data was collected for and the intended new one; the context in which it was collected, and in particular what the people concerned would reasonably expect given their relationship with the organization; the nature of the data, and whether it includes the categories that carry extra protection or data about criminal convictions and offenses; the possible consequences of the intended use for those people; and the safeguards that would apply to it, which may include encryption or pseudonymization. Copies and extracts inherit the limits of the source, so a purpose is not lost when data moves into a warehouse, a test environment or a spreadsheet, and an internal request for personal data is answered against the purpose it was collected for rather than against the seniority of whoever asked.", "crosswalks": { "soc-2": [ "P4.1" ], "gdpr": [ "Art.6(4)" ], "pipeda": [ "4.5", "4.2.4" ] } }, { "key": "personal-data-disclosure-authorization", "name": "Authorized disclosure of personal information", "description": "Personal information leaves the organization only for a purpose it has disclosed and on the consent or other authority it obtained, and that is checked before the disclosure rather than reconstructed after it. Standing disclosures - a processor, a partner, an integration a customer has switched on - are approved in advance, listed, and tied to the purpose and the authority that permits them, and the list is reviewed rather than left to accumulate. A one-off request, including one from a law-enforcement or government body, goes to a named role who establishes what is being asked for, on what authority, and how much of it is genuinely required, and who releases the minimum that answers it; where the organization is permitted to tell the person concerned, it does. A demand that arrives as a judgment of a court or a decision of an administrative authority in another country is not treated as compelling disclosure on its face: it is recognized or enforced only where it rests on an international agreement in force - a mutual legal assistance treaty or equivalent - between that country and the jurisdiction the organization answers to, and where it does not, the organization looks for a separate lawful ground for the transfer instead of complying because a document looked official, takes advice before responding, and records what it decided and why. Everyone who can release personal information knows this is the only route, and a release outside it is handled as an incident rather than as an exception to be tidied up. How MUCH goes out is decided as deliberately as whether anything goes out at all. A disclosure made on a ROUTINE AND RECURRING basis is governed by a standing policy or a standard protocol that fixes in advance how much is released for that type of disclosure, so the amount is settled once and applied consistently rather than judged under pressure each time; every other disclosure is measured against written criteria designed to hold the release to what is reasonably necessary for the purpose, and each request is reviewed individually against them. Where a regime permits the organization to rely on the requester’s own representation that what they have asked for is the minimum necessary, that reliance is used only in the cases the regime names and only where it is reasonable in the circumstances. The same discipline runs on the asking side: what the organization REQUESTS from another organization is limited to what is reasonably necessary for the purpose it is asking for, with standard protocols for the requests it makes routinely and criteria plus an individual review for the rest, because an over-broad request invites an over-broad answer and it is the asker who wanted the data. And there is a hard stop at the top of the scale: an entire record about a person is not used, disclosed or requested unless the whole of it is specifically justified as the amount reasonably necessary for the purpose. Asking for the file is the request this forbids. Personal information is also not SOLD. No disclosure is made in exchange for money or for any other thing of value, whether the payment comes from the recipient or from somebody acting for them, unless the person the information is about has authorized that specific exchange - a general permission to disclose is not one, and neither is a term folded into a service agreement. Whether a payment makes a disclosure a sale is read off the closed list of exclusions the regime states rather than argued from intent, and the list is read as a list: a public health disclosure; a research disclosure where the only payment is a fee recovering no more than the reasonable cost of preparing and transmitting the data; a disclosure for treatment or payment; a transfer that accompanies the sale, merger or consolidation of the business or the diligence leading to one; work a service provider performs on the organization’s behalf, paid for by the organization; data handed to the person who asked for it; a disclosure the law requires; and any other permitted purpose where the only payment is such a cost-based fee or a fee another law expressly permits. Anything the list does not reach is a sale. Some purposes are refused outright, however the request arrives and however official it looks. Where a regime prohibits using or disclosing personal information in order to investigate or impose liability on anyone for the mere act of seeking, obtaining, providing or facilitating lawful care - or in order to identify a person for either of those purposes - the request is declined rather than weighed, and the refusal is recorded. Where that prohibition turns on whether the care was lawful, the organization works from the presumption the regime sets rather than from the requester’s characterisation of it: the care is presumed lawful unless the organization actually knows it was not, or the requester has supplied factual information demonstrating a substantial factual basis that it was not.", "crosswalks": { "soc-2": [ "P6.1" ], "hipaa": [ "164.502(a)(5)(ii)", "164.502(a)(5)(iii)", "164.514(d)(3)", "164.514(d)(4)", "164.514(d)(5)" ], "gdpr": [ "Art.48" ], "pipeda": [ "4.5", "7(3)" ] } }, { "key": "personal-data-disclosure-log", "name": "Record of disclosures of personal information", "description": "Every disclosure of personal information to a party outside the organization is recorded as it is made - the date, who received it, what was disclosed, the purpose, and the authority relied on - so the record is built while disclosures happen rather than reconstructed from memory once somebody asks. Disclosures that were not authorized are recorded in the same place, whether the organization detected one itself or was told of one by a recipient, a customer or a regulator, together with what went out, how it happened, and what was done about it - so an unauthorized disclosure is not invisible for having been unintended, and the two kinds can be answered together. On request, an individual is told what personal information the organization holds about them and who it has been disclosed to, drawn from that record and provided inside the time the organization has committed to; where a category of disclosure is left out of what is reported, that exclusion is stated in advance rather than decided request by request. The same record is what makes a downstream correction possible: where personal information is corrected, erased, or its processing restricted, that change is communicated to each recipient the information was disclosed to, so the parties acting on it are working from the corrected position rather than from what they were originally sent. Where communicating it would genuinely be impossible or take disproportionate effort, that conclusion is recorded against the entry with its reason rather than reached silently, and the individual is told which recipients received their information whenever they ask.", "crosswalks": { "soc-2": [ "P6.2", "P6.3", "P6.7" ], "gdpr": [ "Art.19" ], "pipeda": [ "4.9.3" ] } }, { "key": "personal-data-quality", "name": "Quality of personal information", "description": "Personal information is kept accurate, complete and current enough for the purposes it is actually used for, and how accurate that has to be is decided per purpose rather than in general - information used to make a decision about a person carries a higher bar than information used to address an envelope. Sources are chosen and checked against that bar rather than trusted for being upstream, and information that arrived from a third party or was produced by an inference is marked as such, so a reader knows what they are relying on. Information that goes stale is refreshed or retired on a stated cadence rather than left to be assumed current, and information found to be wrong is corrected at the source as well as in the copies taken from it - and where the organization knows it has already been relied on elsewhere, the correction is passed on. Corrections and quality failures are recorded, so a source that keeps producing bad data is fixed rather than repeatedly patched.", "crosswalks": { "soc-2": [ "P7.1" ], "pipeda": [ "4.6", "4.6.1", "4.6.2", "4.6.3" ] } }, { "key": "esg-reporting", "name": "ESG reporting & disclosure", "description": "An accurate summary of ESG performance is maintained or published for stakeholders.", "crosswalks": { "esg-essentials": [ "G.8" ] } }, { "key": "environmental-aspects-impacts", "name": "Environmental aspects & impacts register", "description": "The environmental effects of the organization’s activities are identified and kept in a register - emissions to air, discharges to water and land, hazardous materials handled, and effects on habitats or land use - each with what is being done to avoid, reduce or restore it.", "crosswalks": { "esg-essentials": [ "E.8", "E.10" ] } }, { "key": "climate-risk-assessment", "name": "Climate risk & adaptation assessment", "description": "A periodic assessment of how physical climate hazards and transition effects could disrupt sites, supply, demand or costs, with the response for each significant exposure and an owner.", "crosswalks": { "esg-essentials": [ "E.9" ] } }, { "key": "product-lifecycle-stewardship", "name": "Product & service life-cycle stewardship", "description": "Environmental impact is considered across design, materials, packaging, use and end of life for what the organization sells, and customers are given the information they need to use, maintain and dispose of it with less impact.", "crosswalks": { "esg-essentials": [ "E.11", "S.19" ] } }, { "key": "environmental-obligations-register", "name": "Environmental obligations register", "description": "A current list of the environmental permits, licenses, legal requirements and customer commitments that apply to the organization, each with a named owner, a renewal or reporting date, and evidence of the last check.", "crosswalks": { "esg-essentials": [ "E.12" ] } }, { "key": "employee-wellbeing", "name": "Employee wellbeing & feedback", "description": "Workers have a routine way to give feedback and raise concerns about their working experience, and the organization acts on what it hears - supporting wellbeing and development, and recording what changed.", "crosswalks": { "esg-essentials": [ "S.4" ] } }, { "key": "human-rights-due-diligence", "name": "Human rights commitment & due diligence", "description": "A stated commitment to respect internationally recognized human rights, backed by a periodic review of where the organization could cause, contribute to, or be linked to harm - through its own operations, its workers, its supply chain, or partners it benefits from - with particular attention to groups more exposed to that harm.", "crosswalks": { "esg-essentials": [ "S.6", "S.9", "S.11" ] } }, { "key": "grievance-mechanism", "name": "Grievance & complaint handling", "description": "Anyone affected by the organization - a worker, a customer, a neighbor - has a reachable route to raise a concern or a complaint, including a complaint about how their personal data is handled; every complaint received is recorded together with what was decided and done about it; cases are resolved without undue cost or delay; and outcomes are tracked so recurring causes get fixed. The route is published where the people who might need it will actually see it, and it is reachable by somebody outside the organization who has no account, no contract and no internal contact.", "crosswalks": { "esg-essentials": [ "S.10", "S.17" ], "iso-9001": [ "8.2.1", "10.2.1" ], "hipaa": [ "164.530(d)(2)" ], "soc-2": [ "CC2.3", "P8.1" ], "pipeda": [ "4.10", "4.10.1", "4.10.2", "4.10.3", "4.10.4" ] } }, { "key": "responsible-marketing", "name": "Responsible marketing & substantiated claims", "description": "Marketing, pricing and contract terms are presented truthfully, and every environmental or social claim is backed by evidence held before the claim is published.", "crosswalks": { "esg-essentials": [ "S.15" ], "iso-9001": [ "8.2.2" ] } }, { "key": "product-service-safety", "name": "Product & service safety", "description": "The safety of what the organization sells is assessed before it reaches customers, residual risks are communicated in the instructions and warnings that ship with it, and safety reports and defects are investigated and acted on.", "crosswalks": { "esg-essentials": [ "S.16" ], "iso-9001": [ "8.5.5" ] } }, { "key": "accessible-inclusive-service", "name": "Accessible & inclusive service", "description": "Products, services and support channels are checked for use by people with disabilities and by customers the market underserves, with the barriers found recorded and a plan to remove them.", "crosswalks": { "esg-essentials": [ "S.18" ] } }, { "key": "stakeholder-engagement", "name": "Stakeholder identification & engagement", "description": "The people and groups affected by the organization’s decisions are identified - including the communities around its operations - engaged before decisions that change that impact, and the organization records what it changed as a result.", "crosswalks": { "esg-essentials": [ "G.10", "S.7", "S.20" ], "iso-9001": [ "4.2" ] } }, { "key": "community-contribution", "name": "Local employment, skills & community investment", "description": "Hiring, training and giving are directed toward the communities the organization operates in - local recruitment, apprenticeships or placements where practical, and donations, volunteering or in-kind support aimed at needs the community itself has identified - with what was done recorded.", "crosswalks": { "esg-essentials": [ "S.21", "S.23" ] } }, { "key": "responsible-procurement", "name": "Responsible purchasing practice", "description": "Significant purchasing decisions consider local and smaller suppliers alongside price, and suppliers are paid on the terms agreed - with payment performance monitored, not assumed.", "crosswalks": { "esg-essentials": [ "S.22" ] } }, { "key": "responsible-political-engagement", "name": "Responsible political involvement", "description": "Rules govern lobbying, political contributions and the positions taken through trade associations; what is spent and where is recorded and disclosed where required, and none of it is used to obtain improper influence.", "crosswalks": { "esg-essentials": [ "G.11" ] } }, { "key": "fair-competition", "name": "Fair competition", "description": "Price fixing, bid rigging, market allocation and abuse of a dominant position are prohibited, and the staff who deal with competitors, trade associations or tenders are trained on the line they must not cross.", "crosswalks": { "esg-essentials": [ "G.12" ] } }, { "key": "property-rights-respect", "name": "Respect for property & intellectual property rights", "description": "The organization uses others’ physical, intellectual and traditional property only with the rights to do so - licenses held and tracked for the software, content and brands it uses, and fair payment where use is agreed. That commitment is carried out through a procedure rather than an intention. A record is kept of what the organization is entitled to use and on what terms, and what is actually installed and in use is compared against that entitlement periodically, so over-deployment is found by the organization rather than by an audit. Software, media and content are acquired only from sources the organization has established are entitled to supply them, and proof of entitlement - the license, the agreement, the receipt - is retained for as long as the use continues. The terms attached to each item are observed rather than assumed generous: the permitted number of users or installations, whether it may be copied, modified, embedded in something the organization sells, or used in a commercial setting at all. Open-source components carry obligations too, and the ones attached to each - attribution, notice, source availability, reciprocal licensing of derived work - are identified before the component is adopted and met in what ships. Entitlement is disposed of or transferred deliberately when equipment or a service is retired, and people are told what the rules are so infringement is not casual. Peer-to-peer file sharing on the organization’s systems is a case of its own: it is controlled and its use documented, so the capability cannot become a route for distributing, displaying, performing or reproducing copyrighted work the organization has no right to.", "crosswalks": { "iso-27001": [ "A.5.32" ], "esg-essentials": [ "G.13" ], "nist-800-53": [ "CM-10" ], "fedramp-rev5-class-b": [ "CM-10" ], "fedramp-rev5-class-c": [ "CM-10" ], "fedramp-rev5-class-d": [ "CM-10" ] } }, { "key": "ai-system-inventory", "name": "AI system inventory", "description": "A maintained inventory of the AI systems the organization develops, deploys, or uses, with each system's purpose, owner, and risk classification.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-1.6" ], "ai-governance-essentials": [ "GV.3" ] } }, { "key": "ai-impact-assessment", "name": "AI system impact assessment", "description": "A process to assess the potential impacts of AI systems on individuals, groups, and society, and to document and act on the results. The assessment weighs both sides of the ledger. The benefits expected from the system’s intended functionality and performance are examined and written down, rather than assumed from the fact that somebody wanted to build it. So are the potential costs that follow from an expected or realized error, or from functionality and trustworthiness falling short - including the costs that are not monetary, such as time taken from the people it is used on, harm to those wrongly classified, and the erosion of trust that is expensive to rebuild - and both are read against the organization’s stated risk tolerance rather than against nothing. The team that designs, develops, deploys, evaluates or uses the technology is the team that documents its risks and potential impacts, and it does not stop at documenting them: what it found is communicated more broadly, to the people who take the deployment decision and to those who will live with it. The process is defined before it is used and then run to plan: when an impact assessment is required, who performs it, and against what criteria are settled in advance; it is performed at planned intervals and again when circumstances change; and the results of each are retained as documented information. Impacts on wider society are assessed in their own right alongside impacts on individuals and groups - effects on the environment the system operates in, on economies and livelihoods, on public discourse, and on the institutions people rely on - because a system can leave every individual user unharmed and still move something at that scale.", "crosswalks": { "iso-42001": [ "6.1.4", "8.4", "A.5.2", "A.5.4", "A.5.5" ], "nist-ai-rmf": [ "MAP-3.1", "MAP-3.2", "MAP-5.1", "GOVERN-4.2" ], "ai-governance-essentials": [ "RM.1", "RM.2" ] } }, { "key": "human-oversight", "name": "Human oversight of AI", "description": "Appropriate human oversight of AI systems, so people can understand, monitor, and intervene in how an AI system operates - the named people who hold that oversight have the competence, the authority and the access to the system to exercise it, and the system is operated in the way the instructions supplied with it specify, inside the purpose it was assessed and approved for rather than whatever use it turns out to support. Policy defines and differentiates the roles in each human-AI configuration instead of letting \"a human is involved\" stand for all of them: where a person decides and the system only advises, where the system decides and a person reviews before the outcome takes effect, and where the system acts alone with a person monitoring after the fact - each configuration naming who holds the oversight role, what they are expected to check, and what they are empowered to do about it. The oversight process for a given system is then defined in line with those policies, assessed against whether it actually works in practice rather than on paper, and documented.", "crosswalks": { "iso-42001": [ "A.6.2.6", "A.9.2" ], "eu-ai-act": [ "HREQ-6", "HOBL-5" ], "ai-governance-essentials": [ "HO.1", "HO.2" ], "nist-ai-rmf": [ "GOVERN-3.2", "MAP-3.5" ] } }, { "key": "ai-policy", "name": "AI policy", "description": "A documented, leadership-approved policy for the responsible development and use of AI, aligned with the organization’s other policies and reviewed at planned intervals. The policy is where the AI risk management process is established, rather than the process being whatever practice has grown up: it states how AI risk is assessed, who decides what, which of the organization’s risk priorities make an activity mandatory and which leave it to judgment, and what has to be recorded when a decision is taken. It is written to be read by the people it binds and published to them, so the process and the outcomes it produces rest on transparent policy, procedure and control rather than on the standing of whoever happens to be running it. Top management establishes the policy itself rather than ratifying one drafted beneath it: the policy is appropriate to the organization’s purpose, it provides the frame within which AI objectives are set, and it carries a commitment to meet the requirements that apply and to keep improving the management system. It is kept as documented information, communicated inside the organization, and made available to interested parties where that is appropriate. The policy states boundaries as well as principles - where AI may be used, where it may not, and which uses the organization has decided to prohibit outright - written as a rule somebody can be held to rather than as an aspiration, so that a proposed use can be tested against it before any work starts.", "crosswalks": { "iso-42001": [ "5.2", "A.2.2", "A.2.3", "A.2.4" ], "nist-ai-rmf": [ "GOVERN-1.2", "GOVERN-1.4" ], "ai-governance-essentials": [ "GV.1", "GV.4" ] } }, { "key": "ai-roles-responsibilities", "name": "AI roles & accountability", "description": "Defined and allocated responsibilities for AI across the organization, plus a way for staff to raise concerns about the organization’s AI. Executive leadership holds the decisions about AI risk rather than delegating them out of sight: the decision to develop or deploy an AI system, and the acceptance of the risk that comes with it, is taken by a named executive who answers for it, and the name is recorded with the decision rather than reconstructed afterwards. One owner is named for AI governance as a whole - a single accountable role rather than a committee that shares the answer - and the responsibilities of the teams that build, buy, operate and rely on AI are defined against that ownership, so nothing lands in the gap between two functions.", "crosswalks": { "iso-42001": [ "A.3.2", "A.3.3" ], "nist-ai-rmf": [ "GOVERN-2.1", "GOVERN-2.3" ], "ai-governance-essentials": [ "GV.2" ] } }, { "key": "ai-risk-management", "name": "AI risk management process", "description": "A process to identify, analyze, prioritize, and treat the risks an AI system can pose, tracked over its lifecycle. The organization’s risk tolerances for AI are determined and written down first, and the level of risk management activity a given system attracts is set against them, so a low-stakes internal tool and a system that decides something about a person are not put through the same process by default. Tracking is continuous rather than a single pass: existing, unanticipated and emergent risks are identified regularly by named people working from documented approaches, and are read against both how the system was expected to perform and how it actually performs in the context it was deployed into. Where a risk cannot be assessed with the measurement techniques available, or no metric for it exists yet, that is not treated as an absence - a tracking approach is chosen for it deliberately and recorded, so the risk stays visible while it is unmeasurable. The resources needed to manage AI risk are accounted for as part of the treatment decision, and a viable non-AI alternative system, approach or method is weighed on the same terms as any other mitigation, because not building the system is sometimes what reduces the magnitude or likelihood of the impact most. The process itself is monitored and periodically reviewed on a plan: who reviews it and how often is decided in advance and written down, and both the process and the outcomes it produced are examined, so a process that has quietly stopped surfacing anything is noticed rather than trusted. The assessment is a defined process rather than an exercise: the criteria for accepting AI risk, and the criteria for deciding when an assessment is performed at all, are set in advance and applied the same way each time, so repeated assessments produce consistent and comparable results rather than a different answer depending on who ran them. It is performed at planned intervals and again when a significant change is proposed or has happened - a new intended use, a new model, a new data source, a new population it is used on - and the results of each run are retained as documented information.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-1.3", "GOVERN-1.5", "MAP-1.5", "MEASURE-1.1", "MEASURE-3.1", "MEASURE-3.2", "MANAGE-1.2", "MANAGE-1.3", "MANAGE-2.1" ], "eu-ai-act": [ "HREQ-1" ], "iso-42001": [ "6.1.2", "8.2" ] } }, { "key": "ai-data-governance", "name": "Data governance for AI", "description": "Governance of the data used to develop and operate AI systems: sourcing, quality, provenance, and preparation of training and operational data. Where each training and tuning dataset came from is recorded, and the organization confirms it is permitted to use it for that purpose before the data is used rather than after somebody raises the question. Data is checked for whether it is accurate and appropriate for the people and the cases the system will actually affect - representative of that population rather than of whoever was easiest to collect from - and a shortfall found is recorded and acted on instead of noted. Only the data the AI purpose needs is used: a field nobody can tie to the purpose does not enter the pipeline, and what is used is kept no longer than the purpose justifies, with the retention period stated per dataset and enforced when it ends. Whether the organization processes special categories of personal data to detect and correct bias in reliance on Article 4a of the EU AI Act is decided and recorded either way: an organization that does not rely on Article 4a for that purpose records that it does not, and has nothing further to do under this paragraph. Where it does, the processing happens only exceptionally, only as far as strictly necessary to detect and correct bias, subject to appropriate safeguards for the fundamental rights and freedoms of natural persons and in addition to what EU data protection law already requires, and only while every one of these conditions is met: the bias detection and correction could not be done effectively by processing other data, including synthetic or anonymised data; the data are held under technical limitations on re-use and state-of-the-art security and privacy-preserving measures, including pseudonymisation; the data are secured and protected under suitable safeguards against misuse, with access strictly controlled and documented, so only authorised people under confidentiality obligations can reach the data; the data are not transmitted, transferred or otherwise accessed by other parties; the data are deleted once the bias has been corrected or the retention period ends, whichever comes first; and the records of processing activities kept under EU data protection law state why the processing was strictly necessary and why other data could not have achieved the same objective. A provider of a high-risk AI system relies on Article 4a(1). A deployer of a high-risk system, or a provider or deployer of any other AI system or model, may rely on Article 4a(2) only where the processing is strictly necessary to detect and correct biases likely to affect the health and safety of persons, to have a negative impact on fundamental rights, or to lead to discrimination prohibited under Union law, and then on all of the same conditions. Article 4a itself creates no obligation to carry out bias detection and correction: a high-risk provider’s duty to examine for and address bias comes from Article 10(2), points (f) and (g), and Article 4a governs only whether special-category data may be used to meet it.", "crosswalks": { "iso-42001": [ "A.4.3", "A.7.2", "A.7.3", "A.7.4", "A.7.5", "A.7.6" ], "eu-ai-act": [ "HREQ-2", "GEN-2", "GEN-3", "GEN-4", "GEN-5", "GEN-6", "GEN-7", "GEN-8", "GEN-9" ], "ai-governance-essentials": [ "DA.1", "DA.2", "DA.4" ] } }, { "key": "ai-responsible-development", "name": "Responsible AI development lifecycle", "description": "Objectives and processes for responsible design and development of AI systems, including requirements, design documentation, and controlled deployment. Requirements are elicited from the relevant AI actors rather than assumed by the build team - the people who will operate the system, the people it will be used on, the domain experts, and the functions accountable for it - and they are written so those people can confirm they understood them. \"The system shall respect the privacy of its users\" is a requirement rather than a sentiment only when it is stated as something a test could fail. Design decisions record the socio-technical implications they carry: what a choice does to the people and the process around the system, not only to its measured performance.", "crosswalks": { "iso-42001": [ "A.6.1.2", "A.6.1.3", "A.6.2.2", "A.6.2.3", "A.6.2.5" ], "nist-ai-rmf": [ "MAP-1.6" ] } }, { "key": "ai-verification-validation", "name": "AI verification, validation & robustness", "description": "Testing that an AI system meets its requirements and performs with appropriate accuracy, robustness, and security before and during use. Safety is evaluated on its own terms and on a regular cadence, against the safety risks identified when the system was mapped: the system is demonstrated to be safe before it is deployed, its residual negative risk is shown to sit inside the stated risk tolerance rather than merely to have been reduced by some amount, and it is shown to fail safely - particularly when it is driven beyond the limits of what it knows. The safety metrics used reach reliability and robustness, what is watched in real time, and how quickly a failure of the system is responded to. Validation before go-live is a gate rather than a report: what the system has to demonstrate about meeting its intended purpose and the risk criteria set for it is decided in advance, and a system that does not meet them does not go into service. Performance is tested for stability as well as for accuracy - across the range of inputs, populations and operating conditions the system will actually meet in production, not only on the data it was built on.", "crosswalks": { "iso-42001": [ "A.6.2.4" ], "nist-ai-rmf": [ "MEASURE-2.3", "MEASURE-2.4", "MEASURE-2.5", "MEASURE-2.6", "MEASURE-2.7" ], "eu-ai-act": [ "HREQ-7" ], "ai-governance-essentials": [ "SR.2", "LC.1" ] } }, { "key": "ai-technical-documentation", "name": "AI technical documentation", "description": "Maintained technical documentation of an AI system’s design, development, and impact assessments, sufficient to demonstrate how it works and was built. It states the system’s knowledge limits - what it was built to handle, what it was not, and the conditions under which its output should not be relied on - together with how that output may be used and how a person oversees it, in enough detail that someone deciding whether to act on an output can decide well rather than guess. It also identifies, component by component, the internal risk controls the organization relies on for that component, third-party AI technologies and pre-trained models included, so the controls standing behind a system are documented in one place instead of being inferred from whichever team implemented each part. The documentation is written for the teams that rely on the system as much as for an assessor: its purpose, the data behind it, its limits and the use it is intended for are stated in one place they can find, and are kept current as the system changes rather than fixed at the version that was first written.", "crosswalks": { "iso-42001": [ "A.5.3", "A.6.2.7" ], "eu-ai-act": [ "HREQ-3" ], "nist-ai-rmf": [ "MAP-2.2", "MAP-4.2" ], "ai-governance-essentials": [ "TR.2" ] } }, { "key": "ai-logging-records", "name": "AI system logging & record-keeping", "description": "Automatic recording of events over an AI system’s lifetime, retained to support traceability, monitoring, and post-incident review.", "crosswalks": { "iso-42001": [ "A.6.2.8" ], "eu-ai-act": [ "HREQ-4" ] } }, { "key": "ai-transparency-disclosure", "name": "AI transparency & disclosure", "description": "Clear information for users and interested parties, including disclosing when people are interacting with an AI system and how to use it appropriately. The risks to transparency and accountability that mapping identified are examined and documented in their own right - a decision the system contributed to that could not be explained afterwards, an outcome whose ownership would be unclear if it were challenged, a disclosure that is technically present but not usable by the person it is for - rather than being treated as discharged by the fact that a disclosure exists. The model is explained, the explanation is validated rather than asserted, and both are documented; the system’s output is interpreted within the context it is used in, so that what an output means, and what it does not mean, informs responsible use and the governance decisions taken on top of it. Negative residual risk - what is left unmitigated after treatment - is written down and passed to the people who will actually carry it: downstream acquirers who will build on the system, and end users who will act on what it produces. People are told when they are interacting with an AI system, and when AI materially shapes a decision about them, at the point it happens rather than in a policy they would have to go looking for. The basis of a consequential AI-assisted decision can be given to the person it was about in plain terms - what mattered, and what would have had to be different - rather than only as a technical account that satisfies an engineer. Information owed to parties outside the organization is provided rather than waited for: what external interested parties need to know about the organization’s AI systems - regulators, customers, the people a system is used on, and those who represent them - is determined, and there is a route by which they receive it and can come back with a question.", "crosswalks": { "iso-42001": [ "A.8.2", "A.8.3", "A.8.5" ], "eu-ai-act": [ "TRANS-1", "HREQ-5" ], "nist-ai-rmf": [ "MEASURE-2.8", "MEASURE-2.9", "MANAGE-1.4" ], "ai-governance-essentials": [ "TR.1", "TR.3" ] } }, { "key": "ai-monitoring-incidents", "name": "AI monitoring & malfunction reporting", "description": "Ongoing monitoring of AI systems in operation, with a process to detect, communicate, and report malfunctions and serious incidents. The process covers the risk nobody anticipated as well as the failure modes that were designed for: when a previously unknown risk is identified, there are procedures to follow rather than a meeting to convene - contain it, decide whether the system keeps running while it is understood, recover the service and the people it affected, and feed what was learned back into the risk record - and those procedures are actually followed and the run of them recorded. Monitoring is aimed at what degrades quietly as well as at what breaks: drift in the data or in the population, degradation in accuracy, and outcomes nobody expected are watched against a baseline recorded at deployment, on a stated cadence, with a threshold that triggers action rather than a chart somebody may look at. Incidents and harms are detected, recorded and responded to on a defined route with named responders, and what was learned goes back into the risk record and into the program rather than closing with the ticket.", "crosswalks": { "iso-42001": [ "A.6.2.6", "A.8.4" ], "eu-ai-act": [ "HOBL-5", "HOBL-6", "HOBL-7" ], "nist-ai-rmf": [ "MANAGE-2.3", "MANAGE-4.1", "MANAGE-4.3" ], "ai-governance-essentials": [ "LC.3", "LC.4" ] } }, { "key": "ai-responsible-use", "name": "Responsible use of AI", "description": "Processes and objectives for using AI systems responsibly and within their intended purpose, so deployment stays inside approved boundaries. The value a deployed system was approved for is sustained rather than assumed to persist: mechanisms are in place and actually applied to keep it doing the job as its data, its users and its context drift - scheduled review of whether it still earns its place, retraining or tuning where performance has moved, upkeep of the documentation and the instructions that travel with it, and a recorded decision when the honest answer is that it no longer does.", "crosswalks": { "iso-42001": [ "A.9.2", "A.9.3", "A.9.4" ], "nist-ai-rmf": [ "MANAGE-2.2" ] } }, { "key": "ai-supplier-management", "name": "AI supplier & third-party management", "description": "Allocation of responsibilities with, and oversight of, the suppliers and third parties involved in developing or providing AI systems and components. The technology and legal risks a third-party component carries are mapped before it is adopted and re-checked while it is in use: what the component actually does, what data it was built on, what the license does and does not permit for the organization’s use of it, and whether that use risks infringing a third party’s intellectual property or other rights - with the approach for doing this in place, followed, and the result documented rather than settled in a procurement thread. Pre-trained models taken from outside and built into a system are monitored on the same terms as the parts the organization wrote, as part of regular monitoring and maintenance, because a model nobody here retrains still changes underneath the system when the provider ships a new version, deprecates the old one, or alters the terms it is offered under. And where a third-party dataset or AI system is judged high-risk, a contingency process is written and kept ready for its failure or its compromise - what the organization falls back to, who is authorized to invoke it, how service is carried on or withdrawn, and what the people relying on the system are told - so a dependency the organization does not control has a planned response instead of an improvised one. Diligence comes before the dependency: the governance, security and risk posture of a supplier whose AI the organization will rely on is assessed and the result recorded before the relationship starts, and re-checked while it runs. What the organization requires of third-party AI is then written into the contract rather than left to expectation - what the supplier may do with data it is given, what it must disclose about the model and its limits, what it must tell the organization when something changes or goes wrong, and who answers for an outcome.", "crosswalks": { "iso-42001": [ "A.10.2", "A.10.3" ], "nist-ai-rmf": [ "GOVERN-6.1", "GOVERN-6.2", "MAP-4.1", "MANAGE-3.1", "MANAGE-3.2" ], "ai-governance-essentials": [ "TP.1", "TP.2" ] } }, { "key": "ai-use-case-definition", "name": "AI use case definition & context", "description": "Before an AI system is built or bought, what it is for is written down and agreed rather than carried in the heads of the people building it. The record states the intended purpose and the uses that would be beneficial; the specific task the system will support and the method chosen to implement it - a classifier, a generative model, a recommender - so the technique is a decision that can be questioned rather than an accident of who was available; the context-specific laws, norms and expectations that apply where it will run; and the settings it is prospectively deployed into, with the types of user it will meet and what those users will expect of it. It records the organization’s mission and the goals the technology is meant to serve, and the business value or business context the system is being adopted for - and where the system already exists and is being assessed rather than proposed, that value is re-evaluated rather than inherited from whoever justified it originally. From the system’s capability, that established context and the way the system has been categorized, the targeted application scope is specified and written down: what the system is approved to be used for, and by extension what falls outside it. Assumptions and their limitations are recorded alongside, so a later reader can see what the scope rested on and notice when the ground has moved.", "crosswalks": { "nist-ai-rmf": [ "MAP-1.1", "MAP-1.3", "MAP-1.4", "MAP-2.1", "MAP-3.3" ] } }, { "key": "ai-competence-training", "name": "AI competence & training", "description": "The people and the partners who work with the organization’s AI are trained in AI risk management, pitched at what their duties actually are, so they can carry those duties out consistently with the policies, procedures and agreements that bind them - the people who build, the people who approve, the people who operate, the people who answer for it, and the suppliers and contractors doing any of those on the organization’s behalf. Separately from that awareness, the proficiency of the operators and practitioners who work with a system day to day is treated as a defined process rather than an assumption: what a person must be able to do with this system, including how to read its performance and its trustworthiness characteristics, is set out; they are assessed against it before they are relied on and again periodically; and the assessment is documented. Where relevant technical standards or certifications exist for the work, they are identified and the organization’s position on holding them is recorded rather than left open. Training and proficiency are refreshed when the systems change, when the risks change, or when an assessment showed somebody could not do something the role requires. The human resources the organization’s AI work needs are documented as a resource in their own right: which roles are required, what competencies each must hold, and where the gap sits between that and the people actually available - so a shortfall in people is visible on the same page as a shortfall in compute. The people who operate an AI system or act on its output are trained specifically in what it can and cannot do: the conditions under which its output should not be relied on, the failure modes it is known to have, and the correct way to use it - so its limits are known by the person taking the decision and not only by the team that built it. What each person is given is pitched to what they already bring - their technical knowledge, their experience, and the education and training they have had - and to the setting the system will run in and the people it will be used on, so a clinician, a recruiter and an engineer are not handed the same session. The reach is the organization’s own staff and anyone else dealing with the operation and use of its AI systems on its behalf, and it does not stop at the high-risk ones.", "crosswalks": { "iso-42001": [ "A.4.6" ], "nist-ai-rmf": [ "GOVERN-2.2", "MAP-3.4" ], "ai-governance-essentials": [ "HO.3" ], "eu-ai-act": [ "GEN-1" ] } }, { "key": "ai-interdisciplinary-input", "name": "Interdisciplinary & diverse input to AI decisions", "description": "Decisions about how AI risk is mapped, measured and managed are taken by a group assembled for the purpose rather than by whoever happened to build the system. Across the lifecycle, the people informing those decisions span disciplines - engineering, the domain the system operates in, legal, privacy, security, human factors, and the function that will actually run it - and span demographics, experience and background, because a risk that only shows up for a group nobody in the room belongs to is the risk that gets missed. Establishing the context for a system draws on the same breadth, user-experience expertise included, and on the capacity to see the system socially as well as technically. Who took part is documented, not only what was decided, so participation can be shown rather than asserted. And the opportunity to collaborate across disciplines is created deliberately - a standing forum, a review that one function cannot sign alone, time allocated to it - rather than left to whoever is free that week.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-3.1", "MAP-1.2" ] } }, { "key": "ai-risk-culture", "name": "AI risk culture, testing & information sharing", "description": "The organization’s policies and its everyday practice push toward critical thinking and a safety-first mindset in how AI is designed, developed, deployed and used, and they do it in ways somebody can point at: questions a design review has to answer before a system proceeds, an expectation that someone will argue the case against, time set aside to look for how a system could go wrong before it does, and no cost to the person who says a system is not ready. Practice also has to make the work possible. Testing an AI system - including adversarial and red-team testing against the organization’s own systems - is permitted, resourced and expected rather than merely tolerated. There is a route by which anyone inside the organization, and anyone outside it, can identify and report an AI incident and have it picked up by someone who can act. And what is learned from that testing and from those incidents is shared: internally with the teams who need it, and externally where sharing would help others avoid the same failure and disclosure is appropriate.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-4.1", "GOVERN-4.3" ] } }, { "key": "ai-external-feedback", "name": "External feedback on AI impacts", "description": "There is a stated route by which people outside the team that developed or deployed a system - its users, the communities it affects, and those who represent them - can tell the organization about the individual and societal impacts its AI is having, and a policy that says what happens next: the feedback is collected, considered, prioritized against everything else in front of the team, and integrated, rather than acknowledged and filed. End users and impacted communities can report a problem with a system and appeal an outcome it produced, through a route published where they will actually find it, and what arrives through those channels is folded into the measures the system is evaluated against - so a pattern of complaints moves a metric and not only a queue. Feedback that has been adjudicated - accepted, rejected, or accepted in part, with the reason recorded - is fed back into system design and implementation through a standing mechanism, so it reaches the next version rather than a report nobody reads. The engagement is regular and resourced: named people are responsible for running it, and it covers positive, negative and unanticipated impacts alike, because the impacts nobody predicted are the ones this is usually the only source of.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-5.1", "GOVERN-5.2", "MAP-5.2", "MEASURE-3.3" ] } }, { "key": "ai-evaluation-design", "name": "AI test & evaluation design (TEVV)", "description": "How an AI system will be tested and evaluated is designed in advance and the design is written down, rather than reconstructed afterwards from whatever happened to be run. Scientific integrity and test, evaluation, verification and validation considerations are identified and documented for the system: how the experiment or trial is designed; how data is collected and selected, and whether what was selected is actually available, representative and suitable for the question being asked; what would count as evidence that the system is trustworthy; and how a construct that cannot be measured directly - fairness, usefulness, harm - is turned into something that can be, with the reasoning for that choice on the record. The test sets used, the metrics computed and the tools that produced them are documented in enough detail that another team could repeat the evaluation and get a comparable answer. Where an evaluation involves human subjects it meets the requirements that apply to that, human-subject protection included, and its participants are representative of the population the system will actually meet rather than the population that was easiest to recruit. The measurement is then examined in its own right: the appropriateness of the metrics and the effectiveness of the controls already in place are reassessed on a cadence and updated, informed by reported errors and by the impacts landing on affected communities; and the effectiveness of the TEVV metrics and processes as a whole is evaluated and documented - so a measure that has stopped distinguishing a good system from a bad one is retired rather than kept because everyone is used to it.", "crosswalks": { "nist-ai-rmf": [ "MAP-2.3", "MEASURE-1.2", "MEASURE-2.1", "MEASURE-2.2", "MEASURE-2.13" ] } }, { "key": "ai-independent-expert-review", "name": "Independent & expert review of AI measurement", "description": "The people assessing an AI system are not only the people who built it. Regular assessments and updates involve internal experts who did not serve as front-line developers for that system, independent assessors from outside the team or outside the organization, or both - chosen so that at least one person in the assessment has no stake in the answer. Domain experts, end users, AI actors external to the team that developed or deployed the system, and affected communities are consulted in support of those assessments to the extent the organization’s risk tolerance calls for, and that judgment of extent is itself recorded rather than left implicit. Their input then does specific work rather than sitting in an appendix. It connects the measurement approaches to the contexts the system is actually deployed into, and those approaches are documented. It informs the measurement results on trustworthiness in deployment and across the lifecycle, so that whether the system performs consistently as intended is answered with more than the developers’ own reading of their own tests, and the results are written down. And it is one of the two sources - field data about context-relevant risks and trustworthiness characteristics being the other - from which measurable improvements or declines in performance are identified and documented over time.", "crosswalks": { "nist-ai-rmf": [ "MEASURE-1.3", "MEASURE-4.1", "MEASURE-4.2", "MEASURE-4.3" ] } }, { "key": "ai-fairness-bias-evaluation", "name": "AI fairness & bias evaluation", "description": "Fairness and bias are evaluated as a measurement of their own, against the fairness and bias risks identified when the system was mapped, and the results are documented. The evaluation names the groups it is testing for and why those groups; it states the fairness measure being used and what that measure actually claims - an equal error rate and an equal outcome rate are different claims, and choosing between them is a decision that gets recorded rather than absorbed into a tool default; and it reports results per group rather than only in aggregate, since an average is precisely where a disparity hides. It reaches past the model to the data and to the deployment: bias in what was collected and how it was labeled, bias introduced by how people use or over-rely on the output, and bias that only appears in one of the contexts the system runs in. It is repeated rather than performed once before launch, because the population, the data and the use all move. Where a disparity is found, what was decided about it - mitigated, accepted with a stated reason, or the system not deployed - is recorded with the result rather than left in the analyst’s working.", "crosswalks": { "nist-ai-rmf": [ "MEASURE-2.11" ], "ai-governance-essentials": [ "RM.3" ] } }, { "key": "ai-system-retirement", "name": "AI system deactivation & decommissioning", "description": "An AI system can be turned off, and the organization knows how. Mechanisms exist and are exercised to supersede a system with a replacement, to disengage it from the decisions it feeds, or to deactivate it altogether when its performance or its outcomes turn out to be inconsistent with the use it was intended and approved for - and the responsibility for invoking each of those is assigned to a named role and understood by the people who would have to act, before the day they have to. Decommissioning and phasing a system out is a documented process rather than an unplugging: what depends on the system and what becomes of those dependencies; what is done with the model, the training data and the logs; what is retained so that questions about decisions the system already made can still be answered; what users and affected people are told, and when; and what takes over the function, if anything does. The process is designed so that retiring a system does not raise risk elsewhere or cost the organization the trust it built - an abrupt withdrawal, a silent fallback nobody was told about, and a record destroyed while it was still needed are the three failures it exists to prevent. Rollback belongs to the same capability rather than to a separate hope: a previous version that is known to work is retained and can be returned to, and the route back is exercised rather than assumed to exist.", "crosswalks": { "nist-ai-rmf": [ "GOVERN-1.7", "MANAGE-2.4" ], "ai-governance-essentials": [ "LC.5" ] } }, { "key": "ai-risk-treatment", "name": "AI risk treatment & sign-off", "description": "Every AI risk the assessment surfaced leaves it with a decision attached: mitigate it, avoid it by not building or not deploying, share or transfer it, or accept it as it stands - and the decision names the treatment, the control that delivers it, the person who owns that work, and the date it is due. The treatment is chosen against the criteria the organization set in advance for what it will accept, rather than against what is convenient to implement, and where a treatment leaves risk behind, that residual risk is written down and accepted in writing by the risk owner rather than left as the remainder nobody looked at. Sign-off comes before go-live: a system whose risks have not been treated and approved does not go into service, and the approval is recorded against the version of the system it was given for, so a later change is visibly a new question rather than covered by an old answer. The plan is then carried out and its results retained - what was actually implemented, what it changed about the risk it was raised against, and what is still open - so treatment can be shown to have happened rather than to have been planned.", "crosswalks": { "iso-42001": [ "6.1.3", "8.3" ], "ai-governance-essentials": [ "RM.4" ] } }, { "key": "ai-objectives-planning", "name": "AI objectives & planning", "description": "The organization sets objectives for what its management of AI is meant to achieve, at the functions and the levels that have to deliver them, and plans the work that gets there. Each objective is consistent with the AI policy, measurable where measuring it is possible and stated so its achievement can be judged where it is not, and it takes account of the risks and impacts the organization has identified and of the requirements that apply to it. The plan behind each objective is written rather than assumed: what will be done, which resources it needs, who is responsible for it, when it is due, and how the result will be evaluated. Objectives are communicated to the people whose work delivers them, monitored while they run, updated when what the organization does with AI changes, and retained as documented information rather than restated from memory at the next review.", "crosswalks": { "iso-42001": [ "6.2" ] } }, { "key": "ai-performance-evaluation", "name": "AI management performance evaluation", "description": "What the organization will monitor and measure in order to know whether its management of AI is working is decided in advance and written down: which processes and which controls, by what method, who performs the measurement and when, and who analyzes and evaluates the results and when. The methods are chosen so that repeating them produces comparable results rather than a different answer depending on who ran them and in which quarter. The results are retained as documented information, and the evaluation - what the numbers say about whether the management system is performing and whether its controls are effective, not merely what they count - reaches the people who decide what to do about it, in time for them to do it. What is measured covers the management of AI and not only the AI: how long a concern raised about a system takes to reach a decision, how many systems went live without the assessment they required, whether the objectives set are being met and by how much - so a program that is producing documents but not outcomes is visible as one.", "crosswalks": { "iso-42001": [ "9.1" ] } }, { "key": "ai-resource-documentation", "name": "AI resource documentation", "description": "What it takes to develop and operate the organization’s AI is identified and documented rather than inferred from whoever happens to be running it. The record covers the resources each AI system depends on and, for each, enough detail that somebody else could take it over: what it is, what it is used for, who provides it, and what happens if it stops being available. The tools used to build and run AI systems are documented by name and version - the frameworks and libraries, the development and experiment-tracking environments, the evaluation harnesses, and the deployment tooling - together with the purpose each serves, so a result that cannot be reproduced can be traced to the toolchain that produced it. The systems and computing resources are documented on the same terms: the compute the organization trains and serves on, where it physically or contractually sits, the storage and networking behind it, and the capacity actually available against what the workload needs. The record is kept current as tools are adopted or dropped and as capacity changes, and it is read together with the data and human resources documented elsewhere, so the full account of what an AI system requires is assembled rather than scattered across the teams that each hold a piece of it.", "crosswalks": { "iso-42001": [ "A.4.2", "A.4.4", "A.4.5" ] } }, { "key": "ai-customer-responsibilities", "name": "AI responsibilities toward customers", "description": "What the organization owes the customers of its AI systems is determined and then discharged, rather than settled case by case when a customer asks. The account covers what a customer must be told before they commit - what the system does and does not do, the conditions it was built for, the known limits on its output, and what the organization expects of the customer in using it safely - and what they are entitled to afterwards: support, notice of a change that alters behavior they depend on, notice of a defect or an incident that affects them, and a route to raise a problem and get an answer with somebody accountable at the end of it. Where the customer is themselves putting the system in front of other people, the information they need to meet their own obligations is provided rather than withheld as proprietary. The responsibilities are written into the terms the relationship runs on so that they bind, and they are reviewed when the system, its intended use, or the requirements that apply to it change.", "crosswalks": { "iso-42001": [ "A.10.4" ] } }, { "key": "ai-prohibited-practices-screening", "name": "Prohibited and high-risk AI use screening", "description": "Every intended use of AI is screened against the categories the organization has decided it will not pursue and the categories that trigger heightened obligations, before development or procurement starts and again whenever the intended use changes. The prohibited list is stated as specific practices rather than as a principle, so that a proposal can be tested against it: an AI system that uses subliminal, purposefully manipulative or deceptive techniques to materially distort a person’s behavior in a way that causes or is reasonably likely to cause significant harm; one that exploits vulnerabilities of age, disability, or a specific social or economic situation to the same effect; one that evaluates or classifies people over a period of time by their social behavior or their personal characteristics, where the resulting social score leads to detrimental treatment in a context unrelated to where the data came from, or to treatment out of proportion to the behavior; one that predicts the risk of a person committing a criminal offense based solely on profiling or on assessing personality traits; one that creates or expands facial-recognition databases through untargeted scraping of facial images from the internet or from CCTV footage; one that infers the emotions of a person in the workplace or in an education institution, outside medical or safety purposes; one that categorizes individuals by their biometric data in order to deduce race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation; real-time remote biometric identification in publicly accessible spaces for law enforcement, which is barred except in the narrow, separately authorized circumstances the law itself sets out; one that generates or manipulates realistic images, video, audio or similar material showing an identifiable person’s intimate parts, or that person engaged in sexually explicit activities, without their freely given, specific, informed, unambiguous and explicit consent; and one that generates or manipulates child sexual abuse material or a pornographic performance, outside a “without right” defence available under national law. The last two were added to the prohibited list by Regulation (EU) 2026/1744 and bind from 2 December 2026; each reaches a system whose intended purpose is that output, and also one whose design, capabilities or user-facing functionality make that output a reasonably foreseeable and reproducible result while it carries no reasonable and adequate safeguard to prevent it and to correct misuse that is observed or reported. A proposal that matches one of these is stopped rather than mitigated. A proposal that matches a heightened-risk category is escalated to the people authorized to decide it. The screening result, the reasoning, and the decision are recorded either way, so a use that was allowed is as traceable as one that was refused.", "crosswalks": { "eu-ai-act": [ "PROH-1", "PROH-2", "PROH-3", "PROH-4", "PROH-5", "PROH-6", "PROH-7", "PROH-8", "PROH-9", "PROH-10" ], "ai-governance-essentials": [ "RM.5" ] } }, { "key": "ai-provider-obligations", "name": "Provider obligations for high-risk AI systems", "description": "Where the organization is the provider of a high-risk AI system - it develops one, or has one developed, and places it on the market or puts it into service under its own name or trademark - the duties that attach to that role are held as a list somebody owns rather than distributed across teams until nobody is answerable. The system is made to comply with the requirements set for high-risk AI before it is placed on the market. The provider’s name or registered trade mark, and an address at which it can be contacted, are indicated on the system or, where that is not possible, on its packaging or accompanying documentation. The documentation the law requires is kept at the disposal of national competent authorities for the full retention period, and the logs the system generates automatically are kept where they are under the provider’s control. Corrective action is taken, and the necessary information given, where a system already placed on the market is found not to conform. Conformity is demonstrated to a national competent authority on a reasoned request, which means the file is assembled and current rather than assembled when asked. Accessibility requirements are met. Each duty has a named owner and a record showing it was discharged for the specific system - because the obligation attaches to the role and not to the organization’s intentions: a deployer of somebody else’s system does not carry these, and an organization that puts its own name on a bought-in system does.", "crosswalks": { "eu-ai-act": [ "HOBL-1" ] } }, { "key": "ai-quality-management-system", "name": "Quality management system for high-risk AI", "description": "A provider of a high-risk AI system runs a documented quality management system that ensures the system complies with what the law requires, set out systematically as written policies, procedures and instructions rather than as practice people have absorbed. It covers the strategy for regulatory compliance, including how conformity assessment is approached and how modifications to the system are managed; the techniques and systematic actions used for design, design control and design verification, and for development, quality control and quality assurance; the examination, test and validation procedures carried out before, during and after development, and how often each is run; the technical specifications and standards applied, and, where a harmonized standard is not applied in full or does not cover a requirement, the means used instead to meet it; the systems and procedures for data management, across acquisition, collection, analysis, labeling, storage, filtration, mining, aggregation and retention; the risk management system; the setting up, implementation and maintenance of post-market monitoring; the procedures for reporting a serious incident; the handling of communication with national competent authorities, notified bodies, other operators and customers; record-keeping of the relevant documentation and information; resource management, including measures related to security of supply; and an accountability framework stating what management and other staff are each responsible for across all of it. How far each part is built out is proportionate to the size of the provider’s organization - but the degree of rigor and the level of protection needed to make the system compliant are not traded away for size.", "crosswalks": { "eu-ai-act": [ "HOBL-2" ] } }, { "key": "ai-conformity-assessment", "name": "Conformity assessment, EU declaration & CE marking", "description": "Before a high-risk AI system is placed on the market or put into service, it goes through the conformity assessment procedure that applies to it - and which procedure that is, assessment based on internal control or assessment involving a notified body, is a determination the organization records with the reasoning behind it, because the answer turns on which category the system falls in and on whether harmonized standards or common specifications were applied in full. Where a notified body is involved, its engagement, its findings and its certificate are held with the system’s file, and the appeal route against its decisions is known before it is needed. The provider then draws up a written EU declaration of conformity for each system, keeps it at the disposal of national competent authorities for the full period required, keeps it up to date, and treats drawing it up as the point at which responsibility for compliance is assumed rather than merely recorded. The CE marking is affixed to the system - or, where that is not possible, to its packaging or accompanying documentation - visibly, legibly and indelibly, in digital form where the system is provided digitally and the marking can be reached from the interface, and followed by the identification number of the notified body where one was involved. A substantial modification to a system that has already been assessed sends it back through a new conformity assessment, whether or not the modified system is distributed further or simply stays in use with the current deployer; and where a system continues to learn after being placed on the market, which changes were pre-determined at the original assessment and written into the technical documentation is settled at the time rather than argued afterwards.", "crosswalks": { "eu-ai-act": [ "HOBL-3" ] } }, { "key": "ai-eu-database-registration", "name": "EU database registration for high-risk AI", "description": "Registration in the EU database is treated as a gate in front of a system going live rather than as paperwork that follows it. The provider, or its authorized representative where it has one, registers both itself and the system in the database before the system is placed on the market or put into service, in the cases the law requires it. The same act is required where a provider has concluded that a system on the high-risk list is not in fact high-risk: that conclusion and the system are registered rather than kept internal, because the assessment is precisely what is being made visible. A deployer that is a public authority, a Union institution or body, or a person acting on their behalf, registers itself, selects the system and registers its use before putting the system into service or using it. Which section of the database an entry belongs in, and the reduced set of information that applies in the law enforcement, migration, asylum and border-control areas, is determined and recorded rather than defaulted. The organization keeps its own record of what was registered, when, and by whom, and updates the entry when what it describes changes - so the public record and the organization’s own account of its systems do not drift apart.", "crosswalks": { "eu-ai-act": [ "HOBL-4" ] } }, { "key": "ai-synthetic-content-marking", "name": "Marking of AI-generated and manipulated content", "description": "Where the organization provides an AI system that generates synthetic audio, image, video or text - a general-purpose AI system included - the system is designed and developed so that its outputs are marked in a machine-readable format and are detectable as artificially generated or manipulated. The marking is a technical solution held to a standard rather than a line in the terms of service: it is effective, interoperable, robust and reliable as far as is technically feasible, judged against the specificities and the limits of the content type, what implementing it costs, and the generally acknowledged state of the art - and it is re-tested when the generation pipeline changes, because a marking that survived last quarter’s encoder is not evidence about this one. The organization records which of its systems this applies to and which it has determined it does not: a system performing an assistive function for standard editing, or one that does not substantially alter the input the deployer provided or the meaning of it, with the reasoning written down, so an exclusion is an argument on the page rather than a silence. Separately from the machine-readable case, content that is generated or materially altered by AI is labeled to the people who will see it wherever its nature would otherwise mislead them, in terms they will actually read, at the point they encounter it.", "crosswalks": { "eu-ai-act": [ "TRANS-2" ], "ai-governance-essentials": [ "TR.4" ] } }, { "key": "ai-deepfake-disclosure", "name": "Deep fake and published AI text disclosure", "description": "Where the organization deploys an AI system that generates or manipulates image, audio or video content constituting a deep fake, it discloses that the content has been artificially generated or manipulated. The disclosure reaches the person seeing the content clearly and distinguishably, at the latest at the time of first exposure, and it conforms to the accessibility requirements that apply, so it is available to people who cannot perceive it the usual way. Where the content forms part of an evidently artistic, creative, satirical, fictional or analogous work or program, the duty narrows to disclosing the existence of the generated or manipulated content in a manner that does not hamper the display or enjoyment of the work - a narrower duty rather than an exemption, and the judgment that it applies is recorded. A second case runs alongside it: text generated or manipulated by AI and published to inform the public on a matter of public interest is disclosed as such, unless a natural or legal person held editorial responsibility for the publication after a process of human review or editorial control - and where the organization relies on that, who held the responsibility and what the review consisted of is recorded rather than asserted. This is a duty of the deployer, and it is not discharged by a provider’s machine-readable marking, which serves a different audience and a different purpose.", "crosswalks": { "eu-ai-act": [ "TRANS-3" ] } }, { "key": "ai-biometric-emotion-notice", "name": "Notice for emotion recognition & biometric categorization", "description": "Where the organization deploys an emotion recognition system or a biometric categorization system that it is permitted to run, the people exposed to it are informed of the system’s operation - what it does, that they are subject to it, and where to find out more - clearly and distinguishably, at the latest at the time of first exposure, and in a form that conforms to the applicable accessibility requirements. Notice reaches everyone exposed rather than only those who interact with the system deliberately, because exposure to a biometric or emotion-inference system is usually passive: a person walks into range rather than opening an app. The personal data such a system processes is handled under the data-protection law that applies to it, on a recorded lawful ground, with retention and the rights of the people concerned settled as they would be for any other processing rather than treated as incidental to the system. Where the organization relies on the narrow permission the law provides for detecting, preventing or investigating criminal offenses, the basis for relying on it and the safeguards applied are recorded, because the notice duty otherwise stands. This is a deployer’s duty, and running a permitted system without telling the people in front of it is the failure it exists to prevent.", "crosswalks": { "eu-ai-act": [ "TRANS-4" ] } }, { "key": "gpai-model-documentation", "name": "General-purpose AI model technical documentation", "description": "A provider of a general-purpose AI model draws up technical documentation of the model and keeps it up to date, covering the training and testing process and the results of the model’s evaluation, at least to the level of detail the Regulation’s own annex sets as the minimum. The documentation exists in order to be handed over: it is kept ready to provide, on request, to the AI Office and to national competent authorities, which means it is maintained in a form somebody outside the team can read and is not reconstructed from notebooks when the request arrives. Each material change to the model - a new training run, a new released version, a change of data or of evaluation result - updates the documentation rather than accumulating against it, and the version of the documentation is tied to the version of the model it describes, so a reader can tell which model they are reading about. Where the organization relies on the exception for a model released under a free and open-source license that allows access, use, modification and distribution, and whose parameters, architecture information and usage information are publicly available, the basis for relying on it is recorded - together with the fact that the exception does not survive the model being classified as one with systemic risk.", "crosswalks": { "eu-ai-act": [ "GPAI-1" ] } }, { "key": "gpai-downstream-information", "name": "Information for downstream providers of a GPAI model", "description": "A provider of a general-purpose AI model draws up, keeps up to date, and makes available the information and documentation that providers of AI systems intending to integrate the model actually need. The test is what the downstream provider can do with it: understand the capabilities and the limitations of the model well enough to build responsibly on it, and comply with the obligations the Regulation puts on them for the system they are placing on the market - neither of which can be done from a marketing page. The content includes at least the elements the Regulation’s annex enumerates, and it is supplied in a form that travels with the integration rather than being available on request to whoever thinks to ask for it. Intellectual property rights, confidential business information and trade secrets are observed and protected while this is done, which shapes how the information is expressed but is not a reason to withhold what a downstream provider needs in order to meet its own duties. The organization keeps a record of who received which version, so that a downstream provider building on a description that has stopped being true can be told.", "crosswalks": { "eu-ai-act": [ "GPAI-2" ] } }, { "key": "ai-copyright-ip-compliance", "name": "AI copyright & intellectual-property compliance", "description": "The organization checks that what goes into its AI systems, and what comes out of them, respects other people’s intellectual property and the terms the material was made available under. Inputs are checked before use: training and tuning data, models, code and content taken from outside carry licenses, and what each license actually permits for this use - commercial use, redistribution, incorporation into a product the organization sells, retention of the weights derived from it - is established and recorded rather than assumed generous. Outputs are checked as well, because a system can produce material that infringes even where every input was licensed, and what the organization will do when that happens is decided in advance rather than during the complaint. Where the organization provides a general-purpose AI model, it additionally puts in place a policy to comply with Union law on copyright and related rights, and that policy is operative rather than declaratory: it identifies reservations of rights expressed by rightsholders against text and data mining and complies with them, using state-of-the-art technology to do so, and it is revisited as the means of expressing and detecting those reservations move. Who owns the policy, what it requires of a training run before the run starts, and the record of a run having been checked against it are held rather than left with whichever team launched the job.", "crosswalks": { "eu-ai-act": [ "GPAI-3" ], "ai-governance-essentials": [ "DA.5" ] } }, { "key": "gpai-training-content-summary", "name": "Public summary of GPAI training content", "description": "A provider of a general-purpose AI model draws up a summary of the content used to train the model and makes that summary publicly available, following the template the AI Office provides rather than a format of the organization’s own choosing. Sufficiently detailed is the standard the Regulation sets and the standard the summary is written to: detailed enough for parties with a legitimate interest, rightsholders in particular, to understand what kinds of content the model was trained on and to act on that understanding. The summary is published where it can be found from the model’s own documentation, is dated and versioned against the model release it describes, and is updated when a further training run changes the answer. Producing it is treated as a consequence of the data-provenance record the organization already keeps rather than as a separate research exercise, which is what makes keeping it current possible - a provider that cannot say internally what it trained on cannot publish an honest summary of it.", "crosswalks": { "eu-ai-act": [ "GPAI-4" ] } }, { "key": "gpai-systemic-risk-obligations", "name": "Systemic-risk obligations for GPAI models", "description": "Where a general-purpose AI model the organization provides is one with systemic risk, four further duties run on top of everything required of any such model. Model evaluation is performed in accordance with standardized protocols and tools reflecting the state of the art, and it includes adversarial testing conducted and documented with the explicit aim of identifying and mitigating systemic risks rather than of producing a benchmark score. Possible systemic risks at Union level are assessed and mitigated, their sources included, across the model’s development, its placing on the market and its use - so a risk that arises from how others deploy the model is in scope, not only one that arises in training. Relevant information about serious incidents, and the corrective measures possible against them, is kept track of, documented, and reported without undue delay to the AI Office and, as appropriate, to national competent authorities - which requires a route set up in advance and known to the people who would have to use it at speed, not discovered during the incident. And an adequate level of cybersecurity protection is maintained for the model and for the physical infrastructure it runs on, weights and training pipeline included, since the harm from a model with systemic risk being taken is not the same harm as a general breach. The organization also records how it knows whether the model meets the classification at all, and notifies where the law requires it, so the answer is a position the organization holds rather than one it discovers.", "crosswalks": { "eu-ai-act": [ "GPAI-5" ] } }, { "key": "ai-model-security", "name": "Security of AI models, data & pipelines", "description": "The models, the data behind them and the pipelines that build and serve them are brought inside the organization’s information-security program rather than run as a research environment beside it. Model weights and checkpoints are stored, transferred and backed up under protection matched to what they are worth; training and evaluation data is classified and handled to the rules its classification carries; the training, fine-tuning and deployment pipelines are secured as production systems, with their build integrity, their secrets and their dependencies managed on the same terms as the rest of the estate; and inference endpoints are protected against abuse and against extraction of the model or of the data it was trained on. Who can reach any of it is decided on least privilege and enforced rather than documented: reading a model, changing it, changing the data it trains on, altering a prompt or a configuration that shapes its behavior, and deploying any of those into production are separate entitlements, each granted to the smallest set of people who need it, through the organization’s normal request and approval route, reviewed on a cadence and removed when the need ends. Access to production models and production data is kept separate from access to development copies. What was accessed and what was changed is logged, so a question about a model’s behavior can be answered with who touched it and when rather than with who remembers.", "crosswalks": { "ai-governance-essentials": [ "SR.1", "SR.4" ] } }, { "key": "ai-adversarial-resistance", "name": "Adversarial & misuse resistance", "description": "The organization assesses how its AI systems can be manipulated or misused, and reduces what it finds, rather than treating misuse as the user’s fault. The assessment names the attack surface specifically: prompt injection carried in content the system reads, instructions smuggled through documents, tools or retrieved data, jailbreaks that talk a system past its own constraints, poisoning of training or fine-tuning data, extraction of the model or of the data it was trained on, and adversarial inputs designed to produce a wrong answer that looks right. Alongside deliberate attack it covers foreseeable misuse - the uses the system was not built for that a reasonable person would nevertheless try, and the uses a determined person would try on purpose. The systems are tested against these rather than reasoned about: adversarial and red-team exercises are run before deployment and repeated as the system and the techniques against it change, by people given explicit permission and scope to do it, and what they found is recorded with what was done about it. Mitigations are layered rather than singular - filtering on input and on output, constraint on which tools and which data the system may reach, rate limiting and anomaly detection, and human review where the consequence warrants it - because any one of them is bypassable. Exposure that cannot be removed is written down and accepted by somebody named, on the same terms as any other residual risk.", "crosswalks": { "ai-governance-essentials": [ "SR.3" ] } }, { "key": "ai-model-change-management", "name": "Change control for models, prompts & configuration", "description": "A change that can alter how an AI system behaves is controlled and recorded, and what counts is stated rather than left to intuition: the model version or its weights, the prompts and system instructions, the retrieval sources and the content inside them, the tools the system may call, the thresholds and decision rules applied to its output, and the configuration and parameters that shape generation. Each change is requested, reviewed by somebody other than the person making it, approved or refused by a role authorized to decide, and released with a record of what changed, why, who approved it, and when. Behavior is evaluated before and after rather than assumed: the change is run against the system’s evaluation set and its acceptance criteria, and a change that moves a measure the organization cares about is a decision somebody takes rather than a deployment that happens. Every deployed configuration is identifiable after the fact, so an output can be tied to the exact model, prompt and settings that produced it. A known-good previous version is retained so the system can be returned to it. Silent change is the failure this exists to prevent - a provider updating a hosted model underneath the system, a prompt edited straight into production, a retrieval index refreshed with new content - so third-party version changes are tracked and treated as changes the organization has to decide about, even though it did not make them.", "crosswalks": { "ai-governance-essentials": [ "LC.2" ] } }, { "key": "foundation-model-oversight", "name": "Foundation model & AI API oversight", "description": "The third-party foundation models and AI APIs the organization builds on are tracked as dependencies with owners, not consumed as though they were stable infrastructure. The record names each model or API in use, its provider, the specific version or endpoint, which of the organization’s systems depend on it, who owns that dependency, and what the organization would do if it became unavailable. The terms each is offered under are read and recorded rather than accepted: what the provider may do with the inputs sent to it, whether those inputs may be used to train, what is said about the outputs and about who owns them, what the acceptable-use policy forbids the organization from doing with it, and what is promised on availability and on notice of change. The stated limits are recorded beside the terms - the languages, domains and modalities the model is documented as suited to, the evaluations its provider has published, and the uses its provider says it is not for - so a use that has run past them is visible rather than discovered in an incident. The record is reviewed on a cadence and on a trigger: a new version, a deprecation notice, a change to the terms or to the pricing that changes the dependency, or a published finding about the model’s behavior. And a model the organization has come to depend on has a stated fallback - a second provider, an older version retained, or a written decision to accept the outage.", "crosswalks": { "ai-governance-essentials": [ "TP.3" ] } }, { "key": "employment-classification", "name": "Worker classification review", "description": "Exempt/non-exempt and employee/contractor determinations are documented against the governing tests and re-reviewed when a role or engagement changes.", "crosswalks": { "esg-essentials": [ "S.12" ], "us-employment-federal": [ "us.classification.exempt", "us.classification.independent-contractor" ] } }, { "key": "leave-administration", "name": "Statutory leave administration", "description": "A consistent process for statutory leave: eligibility determination, employee and employer notices, designation, and reinstatement on return.", "crosswalks": { "us-employment-federal": [ "us.leave.fmla", "us.leave.userra", "us.leave.federal-jury" ] } }, { "key": "benefits-administration", "name": "Benefit plan administration", "description": "Benefit plans are administered against their plan documents, with participant disclosures and continuation-coverage notices issued within the required windows.", "crosswalks": { "us-employment-federal": [ "us.benefits.cobra", "us.benefits.erisa", "us.benefits.aca-employer", "us.termination.cobra-election-notice" ] } }, { "key": "anti-discrimination-program", "name": "Anti-discrimination & accommodation program", "description": "A published anti-discrimination and anti-harassment policy with reporting routes, a documented investigation procedure, and a consistent process for handling accommodation requests.", "crosswalks": { "esg-essentials": [ "S.3" ], "us-employment-federal": [ "us.antidiscrim.title-vii", "us.antidiscrim.ada", "us.antidiscrim.adea", "us.antidiscrim.gina", "us.antidiscrim.pregnancy", "us.antidiscrim.pwfa" ] } }, { "key": "workplace-notices", "name": "Workplace notices & postings", "description": "Required workplace notices are posted where employees can see them, including for remote staff, and individual notices are delivered when a triggering event occurs. Where a law lets the organization collect, use or disclose an employee’s or a job applicant’s personal information WITHOUT their consent because doing so is necessary to establish, manage or terminate the employment relationship, the informing half of that allowance is performed rather than assumed: the individual is told that their personal information will be or may be collected, used or disclosed for those purposes, and the handling then stays inside those purposes and inside what is necessary for them. Being told is a CONDITION of the allowance and not a courtesy - an organization that has not informed the individual does not have the allowance and is back to needing consent - so the notice is given before or at the point the handling starts, who gives it and at which step of recruitment and onboarding is settled in advance rather than per hire, and what proves it was given is recorded against the individual. A new purpose is a new informing, not a reliance on the version issued on somebody’s first day.", "crosswalks": { "us-employment-federal": [ "us.posting.federal-workplace-posters" ], "pipeda": [ "7.3" ] } }, { "key": "labor-relations-practice", "name": "Protected activity & labor relations", "description": "Policies, handbooks, and manager practice are reviewed so they do not restrain employees acting together on terms and conditions of employment.", "crosswalks": { "esg-essentials": [ "S.14" ], "us-employment-federal": [ "us.labor.nlra-protected-activity" ] } }, { "key": "workforce-reduction-notice", "name": "Workforce reduction notice assessment", "description": "Layoffs, closures, and relocations are assessed against advance-notice thresholds before the decision is executed, so any required notice period can still be met.", "crosswalks": { "us-employment-federal": [ "us.termination.warn" ] } }, { "key": "childrens-privacy-program", "name": "Children’s online privacy program", "description": "A documented assessment of whether the service is directed to children under 13 or has a mixed audience, which operators collect through it, and the notice, consent, parental-rights, minimization, security and retention duties that follow. Where the app ships through an app store, the same assessment carries that store’s audience determination — note Amazon treats under 16 as a child in the EU, Australia and Japan, so the age band recorded must be the widest one that applies.", "crosswalks": { "coppa": [ "312.3" ], "apple-kids": [ "1.3/childrens-privacy-law" ], "google-play-families": [ "families/console/target-audience", "families/requirements/legal-compliance" ], "amazon-child-directed": [ "child-directed/scope/determination", "child-directed/legal/coppa-compliance" ] } }, { "key": "childrens-privacy-notice", "name": "Children’s privacy notice (direct & online)", "description": "Direct notices to parents for each circumstance that triggers one, and a prominent online children’s privacy notice carrying the operator details, collection, use, disclosure and retention information the rule requires. The same notice work satisfies the app stores’ requirements to publish a privacy policy and to disclose everything collected from children, including through SDKs.", "crosswalks": { "coppa": [ "312.4(a)", "312.4(b)", "312.4(c)(1)", "312.4(c)(2)", "312.4(c)(3)", "312.4(c)(4)", "312.4(d)" ], "apple-kids": [ "5.1.1(i)", "5.1.4(b)" ], "google-play-families": [ "families/requirements/data-disclosure" ] } }, { "key": "parental-consent", "name": "Verifiable parental consent", "description": "Verifiable parental consent is obtained and recorded before a child’s personal information is collected, used or disclosed, using a method reasonably calculated to confirm the person consenting is the parent, with separate consent for disclosure to third parties. Note that an app-store parental gate is not the same thing as verifiable parental consent, and neither substitutes for the other.", "crosswalks": { "coppa": [ "312.5(a)(1)", "312.5(a)(2)", "312.5(b)(1)" ], "gdpr": [ "Art.8(1)", "Art.8(2)" ], "apple-kids": [ "5.1.4(a)/birthdate-parental-contact" ] } }, { "key": "childrens-consent-exceptions", "name": "Consent-exception handling for children’s data", "description": "Where children’s personal information is collected without prior parental consent under one of the rule’s narrow exceptions, the purpose limit, use limit, notice and prompt-deletion conditions attached to that exception are documented and enforced.", "crosswalks": { "coppa": [ "312.5(c)(1)", "312.5(c)(2)", "312.5(c)(3)", "312.5(c)(4)", "312.5(c)(5)", "312.5(c)(6)", "312.5(c)(7)", "312.5(c)(8)", "312.5(c)(9)" ] } }, { "key": "parent-review-deletion", "name": "Parent review, refusal & deletion requests", "description": "A documented route for a parent to see the categories of personal information collected from their child, review it after the requester is confirmed to be the parent, refuse further use or collection, and require deletion.", "crosswalks": { "coppa": [ "312.6(a)(1)", "312.6(a)(2)", "312.6(a)(3)" ], "gdpr": [ "Art.15(1)", "Art.17(1)" ] } }, { "key": "child-data-minimization", "name": "Minimized collection in children’s activities", "description": "Games, prize offerings and other activities aimed at children are reviewed so participation is never conditioned on disclosing more personal information than the activity reasonably needs, and the technical identifiers and location signals the app stores prohibit in children’s apps are neither collected nor transmitted.", "crosswalks": { "coppa": [ "312.7" ], "gdpr": [ "Art.5(1)" ], "apple-kids": [ "1.3/no-third-party-transfer" ], "google-play-families": [ "families/requirements/child-only-identifiers", "families/requirements/ad-id-permission", "families/requirements/mixed-identifiers", "families/requirements/phone-number", "families/requirements/child-only-location" ] } }, { "key": "childrens-app-store-declarations", "name": "App-store audience declarations & metadata", "description": "The age and audience declarations made in each app store’s console, and the store-listing metadata, are accurate, kept current when the app changes, and consistent with how the app is actually built and marketed — including the data-safety and content-rating answers the store enforces against. Where a store makes a specific console declaration a condition of appearing in its children’s category at all, that declaration is made and recorded rather than left at a default: Apple conditions the Kids Category on selecting an age band in App Store Connect — ages 5 and under, 6-8, or 9-11 — and the band selected is the one the app is genuinely built for, reviewed when the app changes rather than chosen once for the widest audience that will pass.", "crosswalks": { "apple-kids": [ "1.3/age-band", "2.3.8/for-kids-metadata" ], "google-play-families": [ "families/console/accurate-answers", "families/social/rating-disclosure" ] } }, { "key": "childrens-experience-safeguards", "name": "Child-appropriate experience & parental gates", "description": "Everything a child can reach in the app is age-appropriate, and links out of the app, purchasing opportunities and other adult-facing paths sit behind a parental gate or an equivalent barrier. Covers the store rules on content suitability, thin webview wrappers, augmented-reality safety warnings, and requirements that persist after a kids category is deselected. A gate is a mechanism as well as a placement: Apple defines a parental gate as an adult-level task that has to be completed before the user may continue, so a confirmation a young child can tap through sits in the right place and does not do the job, and what the gate actually asks of a user is designed, tested against the youngest audience the app is built for, and recorded. Content review also covers the prohibitions a store states outright rather than leaving to judgment — including Apple’s rule that an app encouraging minors to consume tobacco or vape products, illegal drugs or alcohol is rejected, which binds on its own terms whether or not the app sits in a children’s category and is not softened by the “excessive amounts” qualifier the general alcohol rule carries.", "crosswalks": { "apple-kids": [ "1.3/parental-gate", "1.3/parental-gate-adult-level-task", "1.3/persisting-requirements", "1.4.3/minors-substance-consumption" ], "google-play-families": [ "families/requirements/app-content", "families/requirements/app-functionality", "families/requirements/ar-safety-warning", "families/requirements/ar-device" ], "amazon-child-directed": [ "child-directed/content/age-appropriate" ] } }, { "key": "childrens-ads-monetization", "name": "Children’s advertising & monetization controls", "description": "Ads and monetization reaching children or users of unknown age come only from sources the store permits, carry no interest-based targeting or remarketing, present age-appropriate creative, and follow the store’s format rules on ad walls, closeability, launch interstitials, multiple placements and virtual currency. The targeting prohibition reaches the use of the data and not only the choice of vendor: no ad shown in any app is selected or targeted using data that came from children, whichever service serves it and whether or not the app sits in a children’s category, so the evidence is the ad configuration and the audience segments in use rather than the SDK inventory alone. Note the stores differ sharply here: Amazon bars its own advertising and affiliate programs outright and parental consent does not lift that, while Google permits certified SDKs and Apple permits contextual advertising only from vendors with published kids policies including human creative review.", "crosswalks": { "coppa": [ "312.5(c)(7)" ], "apple-kids": [ "1.3/third-party-advertising", "2.5.18/kids-data-targeted-advertising", "5.1.4(a)/no-third-party-analytics-advertising" ], "google-play-families": [ "families/ads/certified-sdk-only", "families/ads/no-interest-based-or-remarketing", "families/ads/child-appropriate-content", "families/ads/legal-and-industry-standards", "families/ads-format/no-deceptive-or-inadvertent-clicks", "families/ads-format/no-ad-walls", "families/ads-format/closeable-after-5-seconds", "families/ads-format/no-launch-interstitial", "families/ads-format/no-multiple-placements", "families/ads-format/distinguishable-from-content", "families/ads-format/no-manipulative-tactics", "families/ads-format/no-forced-click-through", "families/ads-format/virtual-currency-distinction" ], "amazon-child-directed": [ "child-directed/ads/no-amazon-programs-to-children", "child-directed/ads/child-only-no-amazon-programs" ] } }, { "key": "childrens-sdk-governance", "name": "Third-party SDK & API governance for children’s apps", "description": "Every third-party SDK and API in a child-directed app is inventoried with what it collects and transmits, checked against terms that permit child-directed use, and either confirmed suitable for children or gated so it collects nothing from them. This is one inventory that answers Apple’s analytics limits, Google’s approved-SDK rules, Amazon’s child-suitability test and COPPA’s diligence duty at once.", "crosswalks": { "coppa": [ "312.8(c)" ], "apple-kids": [ "1.3/third-party-analytics" ], "google-play-families": [ "families/requirements/child-only-sdk", "families/requirements/mixed-sdk", "families/requirements/mixed-sdk-gating" ], "amazon-child-directed": [ "child-directed/sdk/child-suitable", "child-directed/sdk/prohibited-terms" ] } }, { "key": "neutral-age-screen", "name": "Neutral age screening for mixed audiences", "description": "A mixed-audience app establishes a user’s age band with a neutral screen that does not steer or reward a user into misstating their age, treats an unknown age as a child, and uses the result to gate data collection, third-party SDKs and advertising. One implementation is the evidence for the identifier, SDK and ad-serving rules that all depend on knowing which users are children.", "crosswalks": { "google-play-families": [ "families/ads-sdk/mixed-age-screening" ], "amazon-child-directed": [ "child-directed/sdk/mixed-audience-gating" ] } }, { "key": "childrens-social-safety", "name": "Online-safety controls for children’s social features", "description": "Where children can share freeform content or communicate with others, an in-app safety reminder is shown before the first exchange, adults can manage or disable the social features, and adult action is required before a child exchanges personal information. Apps whose main focus is chatting with people the user does not know, or chatting with people anonymously, do not target children at all.", "crosswalks": { "google-play-families": [ "families/social/online-safety-reminder", "families/social/adult-action-gate", "families/social/adult-management", "families/social/anonymous-chat" ] } }, { "key": "external-security-contacts", "name": "Contact with authorities & security communities", "description": "The organization decides in advance which outside bodies it may need to reach about information security, and can reach them without improvising. Two distinct registers are kept. The first names the AUTHORITIES relevant to what the organization does and where it operates - the data protection or supervisory authority, the sector regulator, law enforcement, the national cyber incident body, and the emergency and utility services that matter to its sites - together with what each would be contacted about, the threshold at which contact becomes mandatory rather than optional, who inside the organization is authorized to make it, and the current route in. The second records the SPECIAL INTEREST GROUPS the organization participates in - security forums, professional associations, sector information-sharing bodies, vendor and product advisory lists - which exist so that advisories, techniques and early warning arrive before an incident rather than during one, and so that specialist advice can be obtained on demand. Both registers name an owner, are verified on a stated cadence and after any reorganization, and are reachable by the incident responders at the moment they are needed rather than filed where only their author knows. What may be shared outward through either channel is bounded by the organization’s own classification and confidentiality rules, so participation does not become a disclosure route. What arrives through those channels is acted on rather than received: security alerts, advisories and directives from the external sources the organization has named are taken in on an ongoing basis, generated internally where the organization is the one who found the problem, disseminated to the roles, groups and external parties the organization has decided need them, and - where the item is a DIRECTIVE the organization is bound by - implemented within the timeframe it sets, or the reason it cannot be is notified to the body that issued it rather than left unanswered. The register is not confined to authorities and forums: it also holds the parties who have to be told when an incident happens - the internal staff who must be informed, the service vendors whose platforms are involved, the cyber insurance provider whose policy carries a notification condition, and the information sharing and analysis partners the organization belongs to - and every entry is verified on a defined cadence, so the number in it is current at the moment somebody has to dial it. What arrives is fed into the ANALYSIS and not only into the inbox: the threat intelligence and the contextual information the organization receives - what is being exploited now, against whom, and by what technique - is integrated into how adverse events are analyzed and into the risk assessment, so an alert is interpreted against current knowledge rather than in isolation. The same register is what incident information is shared against: what goes to each designated internal and external party, and at what point in the response, is decided in advance so sharing follows a list rather than whoever is remembered under pressure.", "crosswalks": { "fedramp-rev5-class-d": [ "SI-5(1)", "SI-5" ], "nist-csf": [ "ID.RA-02", "DE.AE-07", "RS.CO-03" ], "cis-controls": [ "17.2" ], "iso-27001": [ "A.5.5", "A.5.6" ], "nist-800-171": [ "3.14.3" ], "nist-800-53": [ "SI-5" ], "fedramp-rev5-class-b": [ "SI-5" ], "fedramp-rev5-class-c": [ "SI-5" ] } }, { "key": "security-in-project-management", "name": "Information security in project management", "description": "Security is addressed inside the project method the organization already uses, so it applies to every project regardless of type - a software build, a system migration, an office move, a new product, an acquisition - rather than only to the ones somebody thought to flag. At initiation each project determines the information security requirements that apply to it, derived from the classification of the information it will touch, the legal and contractual duties attached to it, and the risks the project itself introduces; the requirements are recorded as project deliverables with owners rather than as advice. Security risks are assessed and re-assessed at defined points in the project rather than once at the start, so a change of scope, supplier or architecture is caught while it is still cheap. Security acceptance criteria are agreed before build and are a condition of the project going live: an unmet criterion is a release decision somebody takes and records, not an omission. Responsibility for each requirement is assigned to a named role, and after go-live the project reviews whether the requirements were actually met and hands what it built into normal operational ownership rather than leaving it unowned when the project closes.", "crosswalks": { "iso-27001": [ "A.5.8" ] } }, { "key": "acceptable-use", "name": "Acceptable use of information and assets", "description": "Rules for how information and the assets that hold, process or transmit it may be used are written down, communicated to everyone who works for or with the organization, and acknowledged before access is given. The rules state what is permitted rather than only what is forbidden: what business use covers, what personal use of an organization asset is allowed and where that ends, whether personally owned devices may be used and under which conditions, and what must never be done - installing unapproved software, bypassing a security control, moving information to a personal account or service, or letting somebody else use a credential or a device issued to you. Handling expectations follow the classification of the information rather than the seniority of the person holding it, and the rules reach every stage the asset is in - in use, in transit, in storage, and at return or disposal. Contractors, temporary staff and third parties working on the organization’s behalf are bound by the same rules through the arrangement that engages them. Where use of an asset is monitored, the rules say so and say what is monitored, so monitoring is disclosed rather than discovered. Breaking the rules has a stated consequence that is actually applied, and the rules themselves are reviewed when technology, working patterns or legal obligations change - and where they change materially, the acknowledgment is taken again rather than relying on the one given against an earlier version. The rules also govern EXTERNAL systems: those the organization neither owns nor controls - a personal computer, a home network, a partner’s or customer’s equipment, a public terminal, a consumer service somebody signed up for - and they state the terms on which such a system may be used to access, process or store the organization’s information, or prohibit its use for that purpose where the risk warrants. Where use is permitted, it is permitted only after the organization has verified that the required controls are actually implemented on that system, or has a connection or processing agreement with whoever runs it; permission is not granted on the strength of a request. Behavior on external sites and services is covered explicitly: what may and may not be posted about the organization on social media and other public platforms, and the prohibition on presenting a credential issued by the organization to any external site or application that is not an approved one. The end-user technologies the rules govern are named rather than left to the reader - the laptops and workstations, the remote-access services, the removable media and portable storage devices, the wireless and mobile equipment, and any personally owned device permitted - and each is approved by an authorized role before it is used, recorded as an approved product or service, and used only for the purposes and by the people the rules state.", "crosswalks": { "iso-27001": [ "A.5.10" ], "pci-dss": [ "12.2" ], "nist-800-171": [ "3.1.20" ], "nist-800-53": [ "AC-20", "AC-20(1)", "PL-4", "PL-4(1)" ], "fedramp-rev5-class-b": [ "AC-20", "PL-4", "PL-4(1)" ], "fedramp-rev5-class-c": [ "AC-20", "AC-20(1)", "PL-4", "PL-4(1)" ], "fedramp-rev5-class-d": [ "AC-20", "AC-20(1)", "PL-4", "PL-4(1)" ] } }, { "key": "information-transfer", "name": "Information transfer rules & agreements", "description": "Moving information out of the organization, or between parts of it, is governed by rules that exist before the transfer rather than being decided by whoever is sending it. The rules cover every route information actually travels by and say so explicitly: electronic transfer, including email, file sharing, messaging and system-to-system interfaces; physical transfer, including paper and storage media carried or couriered; and verbal transfer, including calls, meetings and conversations in places where they can be overheard. For each route the rules state what protection is required at the sensitivity level in play, how the recipient’s identity and entitlement are confirmed before anything is sent, and what to do when a transfer goes to the wrong place. Transfers to another organization are covered by an agreement that sets responsibilities, the protection required in transit and at rest afterwards, the technical standards used, what may be onward-disclosed, notification duties when something goes wrong, and what happens to the information at the end. Physical media in transit carry a record of who had custody at each stage and are packaged to reveal tampering. Automated interfaces are treated as transfers too: their endpoints, credentials and payloads are authorized and reviewed rather than left running because they always have been - each such exchange between the organization’s system and another is covered by a written agreement or an equivalent recorded arrangement setting out the interface characteristics, the security and privacy requirements and controls each side carries, the responsibilities of both, and the impact level of the information being communicated, approved before it starts and reviewed and updated on a defined cadence rather than for the life of the connection. The person doing the sharing is helped rather than left to remember: where an authorized user has to decide whether a recipient’s access authorizations match the sharing restrictions attached to the information - a contractual limit, a consent, a classification, an onward-disclosure condition - the organization gives them the means to make that comparison, and automated aids do it for them wherever the systems can.", "crosswalks": { "fedramp-rev5-class-d": [ "CA-3(6)", "AC-21", "CA-3" ], "iso-27001": [ "A.5.14" ], "nist-800-53": [ "AC-21", "CA-3" ], "fedramp-rev5-class-b": [ "CA-3" ], "fedramp-rev5-class-c": [ "AC-21", "CA-3" ] } }, { "key": "ict-supply-chain-security", "name": "ICT supply chain security", "description": "Security expectations follow the technology the organization buys, not just the supplier it bought it from. Before acquisition, the security requirements for an ICT product or service are stated as conditions of purchase, and the supplier is required to propagate them to the sub-suppliers, components and services it in turn depends on rather than absorbing them at its own boundary; where the supplier will not or cannot, that is a recorded acceptance decision rather than a silent gap. The organization establishes what a delivered component is actually made of - the third-party and open-source software inside it, and where it came from - and keeps that record current enough to answer whether a newly published vulnerability affects it. Delivery is verified rather than assumed: the component received matches the one ordered, comes from the expected source, and its integrity can be checked. Through life, the supplier’s security advisories and the product’s support status are watched, so end-of-support arrives as a planned migration rather than as a discovery; and the sourcing risk itself - a supplier failing, being acquired, or ceasing to supply a component with no substitute - is assessed for the components the organization cannot operate without. That assessment is performed as a SUPPLY CHAIN RISK ASSESSMENT in its own right, covering the systems, components and services the organization depends on, and is updated on a defined cadence and whenever the supply chain materially changes - a new supplier, a change of ownership, a relocated manufacturing or support function, a substituted component. The program is written down: a documented supply chain risk management policy with supporting procedures under a named owner, reviewed on a defined cadence; and a supply chain risk management plan covering the whole life of the system from acquisition through operation to disposal, protected from unauthorized disclosure and modification because it maps the organization’s dependencies, and reviewed and updated on a defined cadence. A team is stood up to lead and support that work, drawn from the functions that actually decide - procurement, engineering, security, legal - rather than left as one person’s additional duty. Procurement is one of the controls: the acquisition strategies, contract tools and methods the organization uses are chosen to guard against, identify and mitigate supply chain risk, and agreements with suppliers and other entities in the chain set out what each party must notify the other of, disclose, or otherwise do when something changes or goes wrong. Delivered systems and components are inspected at defined times or on defined events to detect tampering, and an anti-counterfeit policy with supporting procedures exists to detect and prevent counterfeit components entering the estate, to report any that are found to the source, the authorities and the affected parties, and to train the personnel who receive, install and maintain equipment in what a counterfeit looks like across hardware, software and firmware. When an incident happens, information about it is shared with the providers of the affected products and services and with the other parties across the supply chain who need it, rather than treated as internal. For software the organization develops, that record is maintained as a BILL OF MATERIALS covering the third-party components in use and the ones a project intends to adopt, with the risk each component carries noted against it, and it is evaluated on a defined cadence - at least monthly - to pick up a change in a component or the loss of its support rather than waiting for an advisory to arrive. The program is not run beside the others: what the supply chain risk assessment finds enters the organization’s cybersecurity and enterprise risk registers, is assessed on the same criteria as every other risk, and feeds the same improvement process - so a supply chain finding competes for attention on equal terms instead of sitting in a document only procurement reads. How well the practices are working is monitored across the whole life of each technology product and service - at selection, at delivery, in operation and at retirement - rather than assessed once at purchase. And the suppliers the organization could not operate without are assessed BEFORE acquisition, against stated criteria and with the result recorded, so criticality is established while there is still the option not to buy.", "crosswalks": { "fedramp-rules-2026": [ "MAS-CSO-TPR" ], "fedramp-rev5-class-d": [ "SR-9", "SR-9(1)", "IR-6(3)", "RA-3(1)", "SR-1", "SR-2", "SR-2(1)", "SR-5", "SR-8", "SR-10", "SR-11", "SR-11(1)" ], "fedramp-20x": [ "KSI-SCR-MIT", "KSI-SCR-MON" ], "nist-csf": [ "GV.SC-03", "GV.SC-09", "ID.RA-09", "ID.RA-10" ], "cis-controls": [ "16.4" ], "iso-27001": [ "A.5.21" ], "nist-800-53": [ "IR-6(3)", "RA-3(1)", "SR-1", "SR-2", "SR-2(1)", "SR-5", "SR-8", "SR-10", "SR-11", "SR-11(1)" ], "fedramp-rev5-class-b": [ "RA-3(1)", "SR-1", "SR-2", "SR-2(1)", "SR-5", "SR-8", "SR-10", "SR-11", "SR-11(1)" ], "fedramp-rev5-class-c": [ "IR-6(3)", "RA-3(1)", "SR-1", "SR-2", "SR-2(1)", "SR-5", "SR-8", "SR-10", "SR-11", "SR-11(1)" ] } }, { "key": "cloud-service-security", "name": "Security of cloud services", "description": "Cloud services are acquired, used, managed and left through a defined process rather than adopted by whoever signs up first. Before adoption, the information that will go into the service is classified and the security requirements that follow from it are stated; the service is assessed against them; and the decision, with any residual risk, is recorded and owned. The division of responsibility between the provider and the organization is written down PER SERVICE rather than assumed from a general model, so it is clear which side patches, configures, encrypts, monitors, backs up and retains - the gap between two parties each believing the other holds a control is the failure this control exists to prevent. The agreement covers the security the provider will maintain, what it will tell the organization about incidents and changes and how quickly, where the data will be held and processed, who may sub-process it, and what evidence or assurance report the organization will receive. In use, the organization configures and monitors its own side of the boundary - identities, permissions, network exposure, logging and the settings the provider leaves to the customer - and reviews them on a cadence. Exit is planned at entry: what would be returned, in what format, how quickly, how it would be deleted from the provider afterwards, and what would be needed to run without the service. The provider is MONITORED in use and not only assessed at adoption: the activity in the service and the service itself are watched for potentially adverse events - administrative actions, authentication, changes to configuration and permissions, access to data, and the provider’s own status and security notices - drawing on the logs and telemetry the agreement entitles the organization to, and what is found goes to the same place as an event from the organization’s own estate rather than into a separate console nobody watches.", "crosswalks": { "nist-csf": [ "DE.CM-06" ], "iso-27001": [ "A.5.23" ] } }, { "key": "evidence-preservation", "name": "Preservation of evidence", "description": "When an event might lead to disciplinary action, a legal claim, a regulatory proceeding or a criminal referral, the material that would prove what happened is identified, collected, acquired and preserved to a standard that survives being challenged later - and the decision to do that is taken early, because the point at which evidence is lost is usually before anybody decides it mattered. Procedures state who is authorized to collect, what is collected first because it is most perishable, and how a copy is taken so the original is not altered by the act of examining it. Integrity is demonstrable: acquisition is recorded with time, method and operator, a verifiable checksum or equivalent is taken at acquisition, and every subsequent transfer of custody is logged, so the chain from the system to the hearing is unbroken and documented. Material is stored with access restricted to those working the case and retained until the matter is closed rather than until the retention schedule for ordinary records expires - a legal hold overrides routine deletion, and the hold is issued and lifted deliberately. Where the material may be used in more than one jurisdiction, or handed to an authority, the requirements that jurisdiction sets are established before collection rather than after. Where the organization does not hold the skills, it identifies in advance who it would call. The INVESTIGATION’s own actions are recorded on the same terms as the material it handles: who did what, when, with which tool and against which system, written down as the work happens and held under the same integrity and custody controls as the evidence itself - because an investigation that cannot show what it did to the system it examined cannot show that what it took away is unaltered.", "crosswalks": { "nist-csf": [ "RS.AN-06", "RS.AN-07" ], "iso-27001": [ "A.5.28" ] } }, { "key": "compliance-obligations-register", "name": "Legal, regulatory & contractual obligations register", "description": "The organization maintains a register of the legal, statutory, regulatory and contractual requirements that bear on information security and on the information it holds, and records for each one how it is met and who is accountable for meeting it. Entries are specific enough to act on: the obligation, the jurisdiction and entity it applies to, what it actually requires the organization to do, the control or process that discharges it, the evidence that would demonstrate that, and the review date. The register covers the contractual side as well as the statutory - security commitments made to customers, obligations flowed down from them, and terms accepted from suppliers - because a promise in a signed contract binds the organization as firmly as a statute and is more easily forgotten. It records the requirements attached to cryptography specifically, since the use, import, export and disclosure of cryptographic material is restricted differently in different countries and a global service can breach one while complying with another. It is reviewed on a stated cadence and out of cycle when the organization enters a new market, launches a service, signs a significant contract, or a law it is subject to changes; and where an obligation is not currently met, that is recorded as a gap with an owner and a date rather than left as an absence. The register reaches the privacy and civil liberties obligations attaching to the same information as well as the security ones, because a single system usually sits under both and a register carrying only one of them understates what the organization is bound by. It reaches the requirements that attach to the organization’s use of AI on the same terms - the laws, regulations and contractual terms bearing on how an AI system may be built, bought, deployed or used, each recorded with the jurisdiction and entity it applies to, what it actually requires, the control or process that discharges it, who is accountable and when the entry is next reviewed - so an obligation created by a system rather than by a dataset is understood, managed and documented rather than left to whoever built it.", "crosswalks": { "nist-csf": [ "GV.OC-03" ], "iso-27001": [ "A.5.31" ], "nist-ai-rmf": [ "GOVERN-1.1" ] } }, { "key": "policy-compliance-monitoring", "name": "Management review of policy compliance", "description": "Managers check that the work done in their own area of responsibility actually complies with the security policies, topic-specific policies, standards and procedures that apply to it, and they do it on a stated cadence rather than when something goes wrong. This is a first-line duty and is deliberately not the internal audit or the independent review: the person doing it owns the work being checked, which is what makes it frequent and cheap enough to catch drift early, and it is why its findings are not treated as independent assurance. How compliance is determined is defined in advance - what is sampled, what is measured, what evidence is looked at - and automated measurement is used where the system can report it, so the check is against what the systems are doing rather than against what the team believes they are doing. Results are recorded, including compliance found as well as non-compliance, so a trend is visible. Where non-compliance is found, the cause is established rather than the instance simply corrected: if the requirement is unworkable, unclear or unresourced, that is the finding, and the policy or the process changes rather than the same exception being granted repeatedly. Corrective actions carry owners and dates and are tracked to closure, and the results feed the wider oversight of the program rather than staying inside the team. Responsibility for keeping the control set in place between formal assessments sits with a named senior owner rather than with the assessment: the assignment is in writing, the person holding it answers for the program these checks report into, and what was checked, who checked it, what was found and what was corrected is documented and reported to them on the stated cadence rather than kept inside the team that ran the check.", "crosswalks": { "iso-27001": [ "A.5.36" ], "pci-dss": [ "12.4" ] } }, { "key": "confidentiality-agreements", "name": "Confidentiality & non-disclosure agreements", "description": "The organization identifies where a confidentiality or non-disclosure obligation is needed, documents the terms, and puts them in place BEFORE the information is disclosed rather than afterwards. The terms state what information is covered and how it is identified, how long the obligation lasts - including where it must survive the end of the relationship - what the recipient may and may not do with it, whether and to whom it may be passed on further, what has to be returned or destroyed at the end and how that is confirmed, what the recipient must do if it is disclosed by accident or demanded by a court, and what happens if the obligation is broken. Personnel accept terms as part of their engagement and are reminded of the parts that outlive it when they leave; contractors, temporary staff, interview candidates, prospective suppliers and any other party given access are covered by an agreement appropriate to what they will see. A register records who is under which agreement and when each was signed, so the question \"is this person bound?\" is answered from a record rather than from memory. The standard terms are reviewed when law, jurisdiction or the organization’s own information-handling requirements change, and a signed agreement is treated as a condition of access rather than as paperwork that follows it.", "crosswalks": { "iso-27001": [ "A.6.6" ] } }, { "key": "remote-working-security", "name": "Remote and off-site working", "description": "Working away from the organization’s premises - at home, at a customer site, while traveling, or anywhere else - is authorized rather than assumed, and the conditions attached to it are written down and communicated to the people it applies to. The rules address the place as well as the equipment: whether the physical surroundings allow sensitive information to be seen, overheard or picked up, what may be printed and how it is stored and destroyed, and who else in the household or building may come into contact with the device or the information. They address how the organization’s systems are reached, requiring an authenticated encrypted channel and treating any network the worker does not control as hostile. They address what the worker may use, whether personally owned equipment is permitted and on what conditions, and what happens to the organization’s information held on it when the arrangement ends. Support and incident reporting work the same way off site as on it, so a remote worker is not slower to report because the route is unclear. The authorization is revocable, is reviewed when the role or the risk changes, and covers what must be returned or removed when remote working stops. Each TYPE of remote access the organization permits - a virtual private network, a published application or desktop, a management console reached over the internet, a supplier’s support tunnel - carries its own written usage restrictions, configuration and connection requirements, and is authorized as a type before any individual connection is allowed under it. Remote access is monitored and controlled by automated mechanisms rather than by inspection after the fact, and every remote connection is routed through a limited and managed set of access control points the organization operates, rather than terminating wherever a service happens to expose itself. On the device side, split tunneling is prevented so a remote session cannot bridge the organization’s network to an uncontrolled one, unless the split is provisioned deliberately by a means the organization has approved. The places people are permitted to work from are named rather than left open: the alternate work sites the organization allows are documented, the security controls required at each are stated and their effectiveness is assessed rather than assumed, and a worker at one of them can reach security or incident staff at the moment they need to. The order is fixed rather than incidental: a user authenticates to the organization’s own managed VPN and authentication services BEFORE reaching any enterprise resource, so remote access is granted by infrastructure the organization runs rather than by each service deciding for itself. How much a remotely connecting asset may reach is decided on the state of that asset and not only on who is holding it - whether its anti-malware is current, whether its configuration still matches the organization’s secure configuration baseline, and whether its operating system and applications are up to date - and an asset that fails those checks gets reduced access or none rather than the access its user would ordinarily hold. A device that can reach an untrusted network and a sensitive environment in the same working day is treated as the bridge it could otherwise become: the configuration required of it is specified rather than left to its user, malware protection runs on it actively, its security settings cannot be altered by the person using it unless the change is documented and authorized by a named role for a stated period, and it is checked against those requirements before it is allowed to connect rather than after.", "crosswalks": { "cis-controls": [ "12.7", "13.5" ], "iso-27001": [ "A.6.7" ], "pci-dss": [ "1.5" ], "nist-800-171": [ "3.1.12", "3.1.13", "3.1.14", "3.10.6", "3.13.7" ], "nist-800-53": [ "AC-17", "AC-17(1)", "AC-17(2)", "AC-17(3)", "PE-17", "SC-7(7)" ], "fedramp-rev5-class-b": [ "AC-17" ], "fedramp-rev5-class-c": [ "AC-17", "AC-17(1)", "AC-17(2)", "AC-17(3)", "PE-17", "SC-7(7)" ], "fedramp-rev5-class-d": [ "AC-17", "AC-17(1)", "AC-17(2)", "AC-17(3)", "PE-17", "SC-7(7)" ] } }, { "key": "security-event-reporting", "name": "Security event reporting channel", "description": "Everybody who works for the organization has a route to report anything they observe or suspect about information security, and they know what it is without having to look for it. The channel is named in onboarding and in awareness material, is available at the times events actually happen rather than in office hours only, and takes reports from contractors and temporary staff as well as employees. People are told what to report - not only confirmed breaches, but a lost or stolen device, a suspicious message, a control that is not working, a mistaken disclosure, an access somebody should not have, an unfamiliar person in a secure area, a weakness noticed in a system - and told to report promptly rather than after establishing whether it is real, because triage is the organization’s job and not the reporter’s. A report is acknowledged so the reporter knows it arrived, is routed straight into the event assessment and incident process rather than into a queue somebody reads weekly, and its outcome is fed back where that is appropriate, because silence teaches people not to report again. Reporting in good faith carries no penalty even where the reporter caused the event, and that is stated rather than implied; reports are recorded so volume and type can be reviewed for what they say about awareness. Behind the channel sits an assistance resource, not just an inbox: a named function - a help desk, an assistance group, an on-call responder, an external retainer - that is an integral part of the organization’s incident response capability and that ADVISES AND ASSISTS the person reporting, so somebody who has clicked a link or lost a laptop is helped through what to do next rather than told their ticket is open. Automated mechanisms make that assistance and the information behind it easier to reach - a self-service route to the reporting channel and the guidance, current contact details, and the material a responder needs surfaced where the incident is being handled rather than filed elsewhere. The channel is described in a written process rather than only advertised: it states how quickly a report is expected, who it goes to, by what mechanism, and the minimum information a report should carry, and that process is made available to everybody in the workforce rather than held by the team that operates it. It is reviewed on a defined cadence and whenever a change to the organization would alter it. The channel carries information OUTWARD as well as inward: what is known about an adverse event is provided to the staff authorized to act on it and to the tools that handle it - the ticketing, case and detection systems - at the point they need it, so a report does not stop at whoever received it. And every report is TRIAGED AND VALIDATED before it becomes anything else: whether the thing reported actually happened, whether it is what the reporter took it for, and what it should be treated as, decided against written criteria by a role competent to apply them and recorded with the reasoning.", "crosswalks": { "fedramp-rules-2026": [ "IEC-CSO-AIR", "IEC-CSO-FIR", "IEC-CSO-IIR", "IEC-CSO-OIR" ], "nist-csf": [ "DE.AE-06", "RS.MA-02" ], "cis-controls": [ "17.3" ], "iso-27001": [ "A.6.8" ], "nist-800-53": [ "IR-7", "IR-7(1)" ], "fedramp-rev5-class-b": [ "IR-7" ], "fedramp-rev5-class-c": [ "IR-7", "IR-7(1)" ], "fedramp-rev5-class-d": [ "IR-7", "IR-7(1)" ] } }, { "key": "facility-environmental-controls", "name": "Facility environmental protection & utilities", "description": "Two things are protected at each site holding information or equipment that matters: the building against the physical and environmental threats it faces, and the utilities that equipment depends on to keep running. The threats are established from an assessment of the location rather than from a generic list - fire, water ingress and flooding, extremes of temperature and humidity, storm, seismic activity, explosion, civil unrest, vandalism and deliberate attack - and the measures chosen answer that assessment: detection that raises an alarm to somebody who acts, suppression appropriate to what is being protected, siting decisions that keep critical equipment away from known hazards such as basements, external walls and water services, and physical protection where deliberate damage is a realistic threat. Separately, the supporting utilities - electrical power, telecommunications, water, drainage, heating, ventilation and air conditioning - are sized for the load they carry, monitored so a failure raises an alarm rather than being noticed by its consequences, and inspected and tested at the intervals the supplier specifies rather than when they are next thought about. Where continuity requires it, power and telecommunications are provided by more than one path or by standby equipment, and the standby is tested under load. Emergency lighting, emergency shutoffs and the routes to them are provided and known - and each of those is specified rather than assumed. Fire detection and suppression systems are employed and maintained, and are supported by an independent energy source so they still work when the power that started the fire has gone; the detection activates automatically and notifies both the organization’s designated personnel and the emergency responders, rather than sounding into an empty building. Emergency lighting is automatic, activates on a power loss or a disruption, and covers the emergency exits and evacuation routes rather than only the working areas. The capability to shut off power to the system, or to individual components, exists for emergencies; the shutoff controls are placed where authorized personnel can reach them safely and are protected against being operated by anyone else or by accident. An uninterruptible power supply is provided so that, when the primary source fails, the systems either keep running or shut down in an orderly way rather than stopping mid-write. Temperature and humidity are maintained within levels the organization has stated for each facility holding systems, and those environmental controls are themselves monitored so a drift is seen. Protection against water damage includes master shutoff or isolation valves that are accessible, that work, and that the people who would need them in a hurry know the location of.", "crosswalks": { "fedramp-rev5-class-c": [ "PE-13(2)", "PE-10", "PE-11", "PE-12", "PE-13", "PE-13(1)", "PE-14", "PE-15" ], "fedramp-rev5-class-d": [ "PE-11(1)", "PE-13(2)", "PE-14(2)", "PE-15(1)", "PE-10", "PE-11", "PE-12", "PE-13", "PE-13(1)", "PE-14", "PE-15" ], "nist-csf": [ "PR.IR-02" ], "iso-27001": [ "A.7.5", "A.7.11" ], "nist-800-53": [ "PE-10", "PE-11", "PE-12", "PE-13", "PE-13(1)", "PE-14", "PE-15" ], "fedramp-rev5-class-b": [ "PE-12", "PE-13", "PE-14", "PE-15" ] } }, { "key": "secure-area-working", "name": "Working in secure areas", "description": "Rules govern what may happen inside an area the organization has designated as secure, and they apply to everybody in it including its own staff. People are told the rules before they work there and are told them again when the rules change. What the area contains and what goes on inside it is known on a need-to-know basis, so its existence and purpose are not advertised more widely than the work requires. Working alone in the area is either prevented or authorized deliberately, for reasons both of safety and of removing the opportunity for unobserved action; third parties and maintenance staff work under supervision or under an explicit recorded authorization to work unaccompanied. The area is physically locked and checked when it is vacated rather than left secured by whoever happens to leave last. Recording equipment - cameras, audio recorders, and the ones built into personal devices - is restricted or prohibited according to what the area holds, and the restriction is enforced rather than posted. What may be brought in and taken out is controlled, and the controls are consistent with the media and asset rules that apply elsewhere. Compliance with all of this is checked periodically rather than assumed from the fact that the rules exist. Collaborative computing devices and applications - the cameras, microphones, conferencing systems, room hardware and desktop clients that can capture what is happening in a space - are governed on the same terms: remote activation of them is prohibited except in the circumstances the organization has explicitly permitted, and when one is in use that fact is indicated clearly to the people physically present, so nobody is recorded or listened to by a device they believed was idle.", "crosswalks": { "iso-27001": [ "A.7.6" ], "nist-800-171": [ "3.13.12" ], "nist-800-53": [ "SC-15" ], "fedramp-rev5-class-b": [ "SC-15" ], "fedramp-rev5-class-c": [ "SC-15" ], "fedramp-rev5-class-d": [ "SC-15" ] } }, { "key": "equipment-siting-protection", "name": "Equipment siting & protection", "description": "Equipment is placed and protected so that the ordinary conditions around it do not become a security problem. Siting decisions reduce unnecessary access: equipment holding or processing sensitive information is put where people with no business near it do not pass, screens and printed output are positioned so they cannot be read by a passer-by or through a window, and equipment handling information at different sensitivities is separated where handling them together would create exposure. Environmental conditions the equipment is rated for - temperature, humidity, dust, vibration, chemical exposure, electromagnetic interference - are maintained and monitored where a breach of them would cause loss, and equipment is not sited where eating, drinking, smoking or water services create an avoidable hazard. Power supplied to it is conditioned against surge, sag and interruption to the extent the equipment’s importance warrants, and protection against lightning is provided where the site’s exposure calls for it. Equipment operating in a harsher setting than an office - a factory floor, an outdoor cabinet, a vehicle, a customer site - is given protection appropriate to that setting rather than to the one it was specified for. Placement is reconsidered when the room, the workload or the sensitivity of what the equipment handles changes. Output devices are a case of their own and are controlled as such: printers, copiers, scanners, fax machines, monitors, audio devices and anything else that renders information into a form a person can take away is placed and access-controlled so that only individuals authorized for that information can obtain the output - the printed page in the tray, the image on the screen, the sound in the room - rather than relying on whoever collects it first being entitled to it.", "crosswalks": { "fedramp-rev5-class-d": [ "PE-18", "PE-5" ], "iso-27001": [ "A.7.8" ], "nist-800-53": [ "PE-5" ], "fedramp-rev5-class-c": [ "PE-5" ] } }, { "key": "off-premises-asset-protection", "name": "Security of assets off-premises", "description": "An asset that leaves the organization’s premises stays the organization’s responsibility, and the rules for it are set before it goes rather than after something happens to it. Taking an asset off site is authorized, and what left, with whom, and when it is expected back is recorded, so the organization can answer at any moment which of its assets are outside its walls and who holds each one. While off site the asset is not left unattended in a public place, is not stored where it is visible in an unattended vehicle, and is kept in the custody of the person responsible for it rather than handed on informally; where custody genuinely changes, the handover is recorded. Protection follows the manufacturer’s instructions where they exist, and covers the ordinary hazards of being away - theft, loss, damage, extremes of temperature, and being observed while in use. Assets sent by post or courier are packaged so tampering is apparent and tracked to delivery. Equipment permanently sited away from the organization’s premises, including at a home or a customer location, is covered by the same rules and is recorded as being there. Insurance cover for off-site loss is established rather than assumed, and the asset is returned or accounted for when the person holding it leaves or their need for it ends. Travel to locations the organization has assessed as high risk is treated as its own case: the traveler is issued equipment configured for that trip rather than their ordinary device - carrying only the data the trip needs, with the settings and services the risk calls for - and defined safeguards are applied to the equipment and to any media on return, such as inspection, wiping and reimaging before it rejoins the estate, rather than plugging it back in.", "crosswalks": { "iso-27001": [ "A.7.9" ], "nist-800-53": [ "CM-2(7)" ], "fedramp-rev5-class-c": [ "CM-2(7)" ], "fedramp-rev5-class-d": [ "CM-2(7)" ] } }, { "key": "storage-media-management", "name": "Storage media lifecycle management", "description": "Storage media are managed for their whole life rather than only at the point data is written to them, and the scope is both digital and non-digital: the disks, tapes, flash devices and optical media that hold the information, and equally the paper records, printed output, forms and microform that carry the same information in a form no system can wipe. Each is physically controlled and stored securely - held in a place with a stated protection level rather than left where it was last used, and known to be there - so the protection does not depend on the medium happening to be one an access control list can reach. Which types of media are permitted is decided rather than left to what people happen to own, and removable media are registered when issued so the organization knows what exists and who holds it. Taking media off site requires authorization and is recorded. Media carrying sensitive information are encrypted, so a lost item is a lost object rather than a disclosure, and are transported in packaging that resists physical damage and reveals tampering, with delivery confirmed. Media are stored in conditions the manufacturer specifies, and where information must remain readable for longer than the media are rated to last, it is transferred to fresh media before degradation makes that impossible - and where the technology needed to read it is being retired, the ability to read it is retained or the information migrated. More than one copy is held where the information could not be reconstructed from anywhere else. At end of life, media are securely erased to a standard that makes recovery infeasible, or physically destroyed where erasure is not dependable, and what was destroyed, when, by what method and on whose authority is recorded - including for media returned to a supplier or leased equipment being handed back. All of this is written as a documented media protection policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed and updated on a defined cadence. Access to media is restricted to the personnel and roles the organization has authorized for each type, rather than to whoever can reach the cupboard. Media awaiting sanitization or destruction remain physically controlled and stored in a protected area for that whole period, because the interval between \"finished with\" and \"destroyed\" is where media are most often lost. Media that no owner can be identified for are not used at all, and a portable storage device found without an identifiable owner is treated as untrusted rather than plugged in. Media the organization controls may be used on external systems only on terms the organization has set in advance and recorded, rather than at the holder’s discretion. Removable media are encrypted as a class rather than case by case: data written to a removable device is encrypted whether or not somebody has judged that particular item to carry sensitive information, because the judgment is made at the moment of writing and the device is what leaves the building. Each item is recorded against what it holds and how sensitive that is, so the handling it needs, the approval required to move it and the destruction it must eventually receive follow from a register somebody maintains rather than from whoever last touched the medium.", "crosswalks": { "fedramp-rev5-class-d": [ "MP-6(3)", "AC-20(2)", "MP-1", "MP-2", "MP-4", "MP-5", "MP-7" ], "cis-controls": [ "3.9" ], "iso-27001": [ "A.7.10" ], "pci-dss": [ "9.4" ], "nist-800-171": [ "3.1.21", "3.8.1", "3.8.2", "3.8.5", "3.8.6", "3.8.7", "3.8.8" ], "nist-800-53": [ "AC-20(2)", "MP-1", "MP-2", "MP-4", "MP-5", "MP-7" ], "fedramp-rev5-class-b": [ "MP-1", "MP-2", "MP-7" ], "fedramp-rev5-class-c": [ "AC-20(2)", "MP-1", "MP-2", "MP-4", "MP-5", "MP-7" ] } }, { "key": "cabling-security", "name": "Cabling security", "description": "The power and telecommunications cabling that carries information or supports the systems that hold it is protected from interception, interference and damage, because a cable is the one part of the infrastructure that is easy to reach and rarely looked at. Routes into and around the site avoid public and uncontrolled areas where that is practicable, and where it is not, the cable is placed in conduit or otherwise physically protected. Power and data cabling are segregated so that interference does not corrupt what is carried. Patch panels, cable rooms, risers and equipment cabinets are locked and access to them is controlled and logged in the same way as any other secure area. Cabling and ports are labeled well enough to prevent an error during work but not so descriptively that the labeling itself tells an intruder what to target. For links carrying the most sensitive information, additional measures are considered against a stated threat - armored conduit, alternative routing, electromagnetic shielding, fiber in place of copper, or inspection for unauthorized devices attached to the line - and any that are adopted are reviewed as part of the periodic physical inspection rather than installed and forgotten. Work on cabling by contractors is authorized, supervised and recorded. Physical access to the transmission lines themselves - the runs carrying information within the organization’s facilities, and the points at which they can be reached - is controlled specifically to prevent interception, tapping and the physical damage that interrupts service, so a cable is not left accessible simply because it is inside the building. The power equipment and power cabling that serve the systems are protected on the same terms, against damage and destruction as well as against tampering, because the surest way to stop a system is to reach its power rather than its data.", "crosswalks": { "iso-27001": [ "A.7.12" ], "nist-800-53": [ "PE-4", "PE-9" ], "fedramp-rev5-class-c": [ "PE-4", "PE-9" ], "fedramp-rev5-class-d": [ "PE-4", "PE-9" ] } }, { "key": "equipment-maintenance", "name": "Equipment maintenance", "description": "Equipment is maintained so it keeps working, and the maintenance itself is treated as an activity with security consequences rather than as a purely operational one. Servicing follows the supplier’s recommended intervals and specifications, and is carried out only by personnel the organization has authorized for it, whether internal or from a supplier under an agreement that binds them to its confidentiality and security requirements. A record is kept of faults - suspected as well as actual - and of the maintenance performed, so a pattern of failures is visible and the state of any given item is known. Where maintenance requires equipment to leave the site or a third party to have access to what it holds, the information is removed, or the media taken out, or the third party is covered by an arrangement that permits the access, before the work starts rather than during it; insurance and warranty conditions are checked at the same point. Remote maintenance sessions are authorized, authenticated, time-bounded and logged. After maintenance, the equipment is inspected and its security configuration confirmed before it is returned to service, because a service visit is a common way for a setting to be reset without anyone noticing. The practice is governed by a documented maintenance policy with supporting procedures, issued to the roles it binds, owned by a named role and reviewed on a defined cadence. Maintenance is CONTROLLED as an event: it is scheduled, approved and monitored, and a record is kept of the date and time, who performed it, what was done and which components were replaced, whether the work happened on site or elsewhere. Equipment removed from the premises for service is sanitized of the organization’s information first, and where that is not possible the removal is explicitly approved by a role authorized to approve it. THE TOOLS, TECHNIQUES AND MECHANISMS used to maintain a system are controlled in their own right, and the method is approved on the same terms as the instrument: which tools are approved is decided, the techniques and mechanisms by which maintenance may be carried out are approved and recorded rather than left to the technician on the day, their use is controlled and monitored, previously approved tools are reviewed on a cadence and withdrawn where they are no longer appropriate, the tools personnel bring with them are inspected for improper or unauthorized modification before they touch a system, and any media carrying diagnostic or test programs is scanned for malicious code before it is used. Maintenance equipment holding organizational information does not simply leave: it is verified to hold none, or sanitized, or retained by the organization, or its removal is explicitly authorized by a role empowered to do so. NONLOCAL MAINTENANCE - work performed over a network connection rather than at the machine - is approved and monitored, allowed only where the system permits it, authenticated with multi-factor authentication rather than a single shared credential, logged for the whole session, and terminated with the connection torn down when the work is finished rather than left standing. THE PEOPLE are authorized too: a list of authorized maintenance personnel is maintained, their authorizations are verified before access, only authorized personnel perform work, and anyone without the required access authorization is supervised throughout by somebody who has it and who has the technical competence to see what is being done. Support and spare parts for the components the organization cannot run without are obtained within a defined time of a failure, arranged in advance rather than sourced during the outage. Where a component is sent out for service or repair, configuration control over it is maintained while it is away and again after it is serviced and before it goes back into use, so what returns is what left. Maintenance has an end: hardware that can no longer be maintained to the standard the organization requires - parts unobtainable, the supplier’s support withdrawn, a fault rate past what the record will bear - is replaced or removed from service on a decision that names the risk it would otherwise carry, rather than kept running because it still starts.", "crosswalks": { "fedramp-rev5-class-c": [ "MA-5(1)", "MA-1", "MA-2", "MA-3", "MA-3(1)", "MA-3(2)", "MA-3(3)", "MA-4", "MA-5", "MA-6", "SR-11(2)" ], "fedramp-rev5-class-d": [ "MA-2(2)", "MA-4(3)", "MA-5(1)", "MA-1", "MA-2", "MA-3", "MA-3(1)", "MA-3(2)", "MA-3(3)", "MA-4", "MA-5", "MA-6", "SR-11(2)" ], "nist-csf": [ "PR.PS-03" ], "iso-27001": [ "A.7.13" ], "nist-800-171": [ "3.7.1", "3.7.2", "3.7.3", "3.7.4", "3.7.5", "3.7.6" ], "nist-800-53": [ "MA-1", "MA-2", "MA-3", "MA-3(1)", "MA-3(2)", "MA-3(3)", "MA-4", "MA-5", "MA-6", "SR-11(2)" ], "fedramp-rev5-class-b": [ "MA-1", "MA-2", "MA-4", "MA-5", "SR-11(2)" ] } }, { "key": "privileged-access-management", "name": "Privileged access & administrative tooling", "description": "Access that can change a system rather than merely use it is treated as a separate class from ordinary access, and so are the tools that carry that power. Privileged rights are allocated through a documented process on an event-by-event basis rather than standing by default: they are requested against a stated need, approved by somebody other than the requester, granted for a defined period and withdrawn when it ends. They are held on an identity distinct from the person’s everyday account, so routine work does not run with administrative rights, and they require strong authentication including a second factor. Who holds what privilege is reviewed on a cadence and immediately on a role change or departure. Privileged sessions are logged in a way the privileged user cannot alter, and the log is reviewed. Emergency or break-glass access exists as a documented route, and every use is recorded and reviewed afterwards. Separately, UTILITY PROGRAMS capable of overriding system or application controls - system tools, database and configuration editors, debuggers, packet capture, recovery and imaging utilities - are inventoried, removed or disabled where they are not needed, restricted to a named authorized few, kept apart from application software, protected against being reintroduced by a user, and logged when used; anyone holding ordinary application access does not get them by default. Which personnel and roles may hold a privileged account at all is a decided and recorded list rather than an accumulation, and access to the system’s security functions and to security-relevant information - the audit configuration, the access rules, the cryptographic settings, the security tooling itself - is authorized explicitly per role rather than arriving as a side effect of an administrative grant. The periodic review asks whether the privilege is still needed for the work the holder actually does now, and reassigns or removes it where it is not. The technical controls match the rules: a user without privileges is prevented from executing a privileged function rather than only forbidden from doing so, and every execution of a privileged function is written to the log. Where privileged commands or access to security-relevant information are exercised over a remote connection, that is permitted only for needs the organization has documented and only in a form that can be audited afterwards. The separation extends to the machine and not only to the account: administrative work is performed from computing resources dedicated to it and separated physically or logically from the estate used for everyday work, segmented away from the organization’s primary network and without general internet access, so a browser or a mail client is never one process away from the session that administers the environment. ACCOUNTS THAT ARE NOT PEOPLE are governed as their own class rather than as a quiet exception to the rules above: every account used by a system, a service or an application is inventoried with the function it exists for and a named human owner, interactive login by a person is prevented on it unless a specific need is documented and authorized, its credentials are held in a managed secret store rather than in a file, a script, a scheduler or somebody’s memory, they are changed on a defined cadence and whenever a person who could have known them leaves, and they are neither shared between accounts nor reused from one environment to the next.", "crosswalks": { "fedramp-rev5-class-c": [ "AC-2(7)", "AC-6(1)", "AC-6(2)", "AC-6(5)", "AC-6(7)", "AC-6(9)", "AC-6(10)", "AC-17(4)" ], "fedramp-rev5-class-d": [ "AC-2(7)", "AC-6(3)", "AC-6(8)", "SI-4(20)", "AC-6(1)", "AC-6(2)", "AC-6(5)", "AC-6(7)", "AC-6(9)", "AC-6(10)", "AC-17(4)" ], "fedramp-20x": [ "KSI-IAM-ELP", "KSI-IAM-JIT", "KSI-IAM-SUS", "KSI-MLA-ALA" ], "cis-controls": [ "5.4", "12.8" ], "iso-27001": [ "A.8.2", "A.8.18" ], "pci-dss": [ "8.6" ], "nist-800-171": [ "3.1.6", "3.1.7", "3.1.15" ], "nist-800-53": [ "AC-6(1)", "AC-6(2)", "AC-6(5)", "AC-6(7)", "AC-6(9)", "AC-6(10)", "AC-17(4)" ] } }, { "key": "source-code-access-control", "name": "Access to source code", "description": "Source code, the development tools and libraries it is built with, and the repositories and pipelines that hold and move it are treated as assets whose access is controlled rather than as a shared workspace. Read and write access is granted per a defined scheme on business need, is recorded, is reviewed on a cadence, and is removed when someone changes role or leaves; write access to anything that can reach production is narrower than read access and is granted deliberately. Code is held in a managed repository rather than on individual machines, so what exists is known and what changed is attributable to a person. Changes reach a protected branch only through review and approval by somebody other than the author, and a direct push that bypasses that route is prevented technically rather than discouraged. The history is retained and protected against rewriting, so the record of who changed what survives. Build systems, artifact stores and the credentials they use are covered by the same rules, because access to the pipeline is access to what it produces. Secrets are kept out of the repository, detected automatically when one is committed, and treated as compromised and rotated when found rather than merely deleted from the tip.", "crosswalks": { "iso-27001": [ "A.8.4" ] } }, { "key": "secure-configuration-management", "name": "Secure configuration & baselines", "description": "What a secure configuration IS is defined before anything is deployed, and drift away from it is detected rather than discovered. Baselines are written for each class of hardware, software, service and network component the organization runs, covering the settings that carry security consequence: vendor defaults changed, default and unused accounts removed or disabled, unnecessary services, ports, features and sample content removed, logging and time settings enabled, authentication and encryption settings set, and the administrative interfaces restricted. Baselines are derived from a stated hardening source and from the organization’s own requirements, are version-controlled, are approved before use, and are reviewed when the product changes, when a new threat makes a previous setting inadequate, or on a defined cadence. What is actually deployed is compared against the baseline automatically and on a schedule, and a difference raises an alert to somebody who either corrects it or records an approved exception with a reason, an owner and an expiry. Configuration is applied by an automated, repeatable mechanism wherever possible, so a rebuilt system comes back hardened rather than as somebody remembers it. A change to a baseline goes through the change process, and the record of what a system’s configuration was at a given time is retained - previous versions are kept deliberately and for a stated number of generations, so a system can be rolled back to a known-good configuration rather than rebuilt from memory. The settings themselves are set to the most restrictive mode consistent with what the system has to do, and any deviation from that is approved, documented with the operational requirement behind it, and monitored rather than left implicit. LEAST FUNCTIONALITY is the rule the baseline expresses: a system provides only the capabilities its purpose requires, and the functions, ports, protocols, software and services that purpose does not require are disabled, restricted or removed. That is not a one-time act at build - the estate is reviewed on a defined cadence to find functions, ports, protocols, software and services that have become unnecessary or are insecure by current understanding, and what the review finds is disabled or removed. Two artifacts sit alongside the baselines. A configuration management plan states the roles and responsibilities for the process, the process itself, the configuration items that are placed under configuration management and how they are identified, and it is protected against unauthorized disclosure and modification in its own right because it maps the estate. And the documentation for each product is obtained or written at acquisition rather than assumed to be findable later, in two parts. Administrator documentation covers secure configuration, installation and operation, the effective use and maintenance of the security and privacy functions, and the known vulnerabilities in how the administrative and privileged functions are configured and used. User documentation covers the security and privacy functions a user can reach and how to use them effectively, the ways of interacting with the system that keep it secure and protect individual privacy, and what the user is responsible for. Both are kept current, protected, and distributed to the administrators and users who need them. Where documentation is unavailable or does not exist, the attempts to obtain it are recorded and the organization takes a decided response - writing what it needs itself, or treating the gap as a risk. The process itself is a document and not only a set of files: how a baseline is written, approved, applied and reviewed is recorded and re-approved on a defined cadence and whenever a change to the organization would alter it - and network infrastructure carries its own such process rather than being covered by the one written for servers and end-user devices, because the devices, the settings and the people who change them are different. HOW assets are managed is part of the configuration: configuration is held as version-controlled infrastructure-as-code wherever the platform allows, and administrative interfaces are reached only over protocols that authenticate and encrypt the session - an insecure management protocol is not used unless it is operationally unavoidable, and then as a recorded exception. The hardening source is industry-recommended rather than invented here, and the templates reach the whole of an application’s infrastructure - the operating system under it, the database, the web server, the container image, and the platform and software services it is assembled from - so software written in-house cannot weaken the configuration it is deployed onto. The written process is issued as well as held: the hardening policy and the procedures under it go to the people who build, deploy and maintain the components they govern, so the standard is in use by the people it binds rather than merely current in a repository, and each part of it names the role answerable for carrying it out.", "crosswalks": { "fedramp-rules-2026": [ "SCG-CSO-AUP", "SCG-CSO-RSC", "SCG-CSO-SDF", "SCG-ENH-API", "SCG-ENH-CMP", "SCG-ENH-EXP", "SCG-ENH-MRG" ], "fedramp-rev5-class-c": [ "CM-6(1)", "CM-1", "CM-2", "CM-2(2)", "CM-2(3)", "CM-6", "CM-7", "CM-7(1)", "CM-9", "SA-5" ], "fedramp-rev5-class-d": [ "CM-6(1)", "CM-6(2)", "CM-1", "CM-2", "CM-2(2)", "CM-2(3)", "CM-6", "CM-7", "CM-7(1)", "CM-9", "SA-5" ], "fedramp-20x": [ "KSI-CMT-RMV", "KSI-CNA-DFP", "KSI-CNA-EIS", "KSI-CNA-IBP", "KSI-MLA-EVC", "KSI-SVC-ACM" ], "cis-controls": [ "4.1", "4.2", "4.6", "4.7", "4.8", "16.7" ], "iso-27001": [ "A.8.9" ], "pci-dss": [ "2.1", "2.2" ], "nist-800-171": [ "3.4.2", "3.4.6", "3.4.7" ], "nist-800-53": [ "CM-1", "CM-2", "CM-2(2)", "CM-2(3)", "CM-6", "CM-7", "CM-7(1)", "CM-9", "SA-5" ], "fedramp-rev5-class-b": [ "CM-1", "CM-2", "CM-6", "CM-7", "SA-5" ] } }, { "key": "data-masking", "name": "Data masking & pseudonymization", "description": "Where somebody needs to work with data but does not need the real values, the real values are not shown. The organization decides per use which technique fits - masking or truncating part of a value, replacing it with a token that can be mapped back only by a controlled service, pseudonymizing so the link to a person is held separately, generalizing or aggregating so an individual is not distinguishable, or generating synthetic values that carry no real subject at all - and the choice is made on whether the use needs the value to be reversible, on the sensitivity involved, and on any legal requirement that applies. It is applied where the exposure actually happens: in non-production environments, in support and administration tooling, in analytics and reporting, in exports and extracts, and in anything shown to a third party. Who is entitled to see unmasked values is authorized explicitly, is a smaller set than those who see masked ones, and their access is logged. Residual risk is assessed rather than assumed removed - a masked dataset can still identify someone through combination or through a distinctive rare value - and the assessment is repeated when new data is joined to it. Where a mapping back to the real value exists, it is protected at least as strongly as the data it can restore. Processing carried out for archiving in the public interest, for scientific or historical research, or for statistical purposes is held to this discipline as a condition of proceeding rather than as good practice: technical and organizational safeguards are in place for the people the data is about, they give effect to collecting and holding no more than the purpose needs, and pseudonymization is used wherever the purpose can still be served that way. Where the purpose can be achieved by processing that does not permit the people to be identified at all - or no longer permits it - it is achieved that way instead, and the test is applied at the start of the work rather than after a dataset has been assembled. These techniques are what protects the data while it is IN USE, as distinct from at rest or in transit: the values held in an application session, shown on a screen, loaded into an analytic workspace or opened in a support tool are reduced to what the task actually needs, the working copy is protected against alteration on the same terms as the source it came from, and it is disposed of when the task ends rather than left behind in the environment that produced it.", "crosswalks": { "nist-csf": [ "PR.DS-10" ], "iso-27001": [ "A.8.11" ], "gdpr": [ "Art.89(1)" ] } }, { "key": "data-leakage-prevention", "name": "Data leakage prevention", "description": "The organization works out where sensitive information could leave by, and then monitors and controls those routes. It starts from a subject rather than from a tool: the information worth protecting is identified and classified first, because detection that does not know what it is looking for produces noise instead of findings. The routes are enumerated and each is given a decision - outbound email and attachments, web uploads and personal cloud storage, removable media, printing, screenshots and screen sharing, developer and administrative tooling, personal accounts reached from organization devices, and interfaces to third parties - and the control chosen per route is proportionate: blocked, allowed with a warning, allowed but logged, or allowed for an authorized set. Detection covers information in use, in transit and at rest, and an alert goes to somebody who investigates it rather than to a dashboard. Users are told what is monitored and why, before it starts and in terms they can act on, and monitoring is kept within what the law and the employment relationship in each jurisdiction permit. Findings are reviewed for what they say about process as well as intent, because most leakage is somebody trying to get their job done by the easiest route rather than trying to steal. The detection is automated rather than performed by inspection: a tool identifies the sensitive data actually stored, processed and transmitted across the organization’s assets, including data held at a remote service provider on its behalf, and what it finds is fed back into the data inventory, so the record of where sensitive information lives is corrected by observation rather than by recollection.", "crosswalks": { "fedramp-rev5-class-c": [ "SI-4(18)" ], "fedramp-rev5-class-d": [ "SC-7(10)", "SI-4(18)" ], "cis-controls": [ "3.13" ], "iso-27001": [ "A.8.12" ] } }, { "key": "infrastructure-redundancy", "name": "Redundancy of processing facilities", "description": "Redundancy is built into the systems and facilities that process and hold information, to the level the availability requirements for each service actually demand - and those requirements are stated per service first, so redundancy is engineered against a target rather than bought to a feeling. Single points of failure are identified deliberately, component by component and site by site, and each is either removed, duplicated, or accepted as a risk somebody has signed for. Where duplication exists, the standby is sized to carry real production load rather than to exist, and is kept at the same patch, configuration and data currency as the primary so failing over does not mean failing back to an older state. Failover is TESTED on a schedule and after significant change, in a way that actually moves the service rather than confirming that a switch exists, and the time it took is measured against the target. The redundant path is monitored in its own right, so a failed standby is found before the primary needs it. Where redundancy spans providers or regions, the dependency they share - a common network, a common identity service, a common control plane - is identified, because two copies behind one dependency is one copy. An ALTERNATE PROCESSING SITE is established for the essential functions that need one, with agreements permitting the transfer and resumption of those functions within the time the organization has set, equipped and configured to run them - or with the arrangements in place to equip it in time - and carrying security and privacy controls equivalent to those at the primary site. It is separated from the primary site far enough that the same regional event is unlikely to reach both; the problems that would make it hard to reach during a wide-area disruption are identified in advance with explicit mitigations; and the agreements behind it carry priority-of-service provisions consistent with the availability targets, so the organization is not one customer among many at the moment it needs the site. ALTERNATE TELECOMMUNICATIONS are arranged on the same terms: services that permit the essential functions to resume within the defined time when the primary carrier is unavailable, agreements that include priority-of-service provisions - including registering for the national priority scheme where the organization qualifies and needs it - and a check that the alternate does not share a single point of failure with the primary, which is the usual way two carriers turn out to be one.", "crosswalks": { "fedramp-rev5-class-d": [ "CP-7(4)", "CP-8(3)", "CP-7", "CP-7(1)", "CP-7(2)", "CP-7(3)", "CP-8", "CP-8(1)", "CP-8(2)" ], "fedramp-20x": [ "KSI-CNA-OFA" ], "nist-csf": [ "PR.IR-03" ], "iso-27001": [ "A.8.14" ], "nist-800-53": [ "CP-7", "CP-7(1)", "CP-7(2)", "CP-7(3)", "CP-8", "CP-8(1)", "CP-8(2)" ], "fedramp-rev5-class-c": [ "CP-7", "CP-7(1)", "CP-7(2)", "CP-7(3)", "CP-8", "CP-8(1)", "CP-8(2)" ] } }, { "key": "software-installation-control", "name": "Control of software on operational systems", "description": "What software runs on an operational system, and how it got there, is controlled. Installation and update are performed by trained administrators through an approved route, on the authority of a recorded change, rather than by whoever has the credentials at the time; ordinary users cannot install software on systems that hold or reach sensitive information. Only supported versions from sources the organization has established are legitimate are used, license entitlement is held for each, and the vendor’s integrity check on the package is verified before it is applied. A register records what is installed where, so the question of whether a newly announced vulnerability affects the estate is answered from a record rather than a survey. Software that has reached end of support is removed, or its retention is an approved decision with compensating controls and a date, rather than being left because nothing has broken. A previous version is retained and a rollback path is available before a change is applied, and the change is tested somewhere other than production first. Source code and development tooling are not installed on operational systems, and anything installed for a one-off purpose is removed when that purpose ends. The rule is enforced technically and not only administratively: the organization identifies the software it has authorized, and the system permits that software to execute while denying everything else - a deny-all, permit-by-exception allowlist, reviewed and updated on a defined cadence rather than assembled once - so program execution is prevented wherever it falls outside the policies, rules and authorization conditions the organization has set. Software a user installs for themselves is governed by its own stated policy: what a user may install, what requires a request and an approval, what is forbidden outright, and how compliance with that policy is monitored on a defined cadence rather than assumed. MOBILE CODE - the code that arrives with content and runs on the receiving system, such as scripts, applets, embedded macros and active content in documents and email - is defined into acceptable and unacceptable categories with the reasoning recorded, and its use is authorized, monitored and controlled by mechanism rather than by instruction. The allowlist reaches below the application. Only authorized software LIBRARIES - the shared and system modules a process loads at run time - may be loaded, and anything outside that set is blocked from loading rather than merely discouraged. Only authorized SCRIPTS execute, established by digital signature and version control rather than by the file happening to sit in the right place. Both sets are reassessed on a defined cadence. Software found installed that is not on the authorized list is removed from use or covered by a documented exception, and the estate is reviewed for that on a defined cadence rather than at the next audit. Browsers and email clients are governed as their own case, because they are where untrusted content arrives: only fully supported ones are permitted to run, and only at the version the vendor currently ships. Their plugins, extensions and add-ons are restricted on the same terms - anything unauthorized or no longer needed is uninstalled or disabled rather than left because somebody once installed it.", "crosswalks": { "fedramp-rev5-class-d": [ "CM-14", "SI-7(15)", "CM-7(2)", "CM-7(5)", "CM-11", "SC-18" ], "nist-csf": [ "PR.PS-02", "PR.PS-05" ], "cis-controls": [ "2.3", "2.5", "2.6", "2.7", "9.1", "9.4" ], "iso-27001": [ "A.8.19" ], "nist-800-171": [ "3.4.8", "3.4.9", "3.13.13" ], "nist-800-53": [ "CM-7(2)", "CM-7(5)", "CM-11", "SC-18" ], "fedramp-rev5-class-b": [ "CM-11" ], "fedramp-rev5-class-c": [ "CM-7(2)", "CM-7(5)", "CM-11", "SC-18" ] } }, { "key": "web-filtering", "name": "Web filtering", "description": "Access from the organization’s systems to external websites is filtered so that people are not relying on their own judgment to avoid a site built to attack them. The categories blocked are decided and written down rather than inherited from a vendor default: sites known to distribute malware, phishing and credential-harvesting pages, command-and-control infrastructure, anonymizing and tunnelling services used to evade the organization’s own controls, unsanctioned file-sharing and personal cloud storage, and whatever other categories the organization decides against for legal or conduct reasons. The rule set is kept current from a maintained source, because the value of the control is entirely in how fresh it is. A blocked page tells the user what happened and how to ask for it, so the control does not simply push work onto an unmanaged device. Exceptions are requested, approved by a named role, time-bounded and recorded, and reviewed rather than accumulating. Filtering follows the device rather than the office network, so it still applies when someone works remotely. Users are told what is filtered and what is logged; where encrypted traffic is inspected, the categories exempted from inspection for privacy or legal reasons are defined, and the practice is disclosed rather than discovered. The filtering is not optional in the path: the internal traffic the organization has defined as needing it is routed to external destinations through authenticated proxy servers at its managed interfaces, so a client cannot reach the internet by a route that bypasses the control, and the proxy authenticates both the user and itself rather than acting as an anonymous relay. Filtering is applied at name resolution as well as at the request: a DNS filtering service is used on end-user devices, on premises and remote alike, so a lookup for a domain known to be malicious fails before a connection is ever attempted.", "crosswalks": { "cis-controls": [ "9.2", "9.3" ], "iso-27001": [ "A.8.23" ], "nist-800-53": [ "SC-7(8)" ], "fedramp-rev5-class-c": [ "SC-7(8)" ], "fedramp-rev5-class-d": [ "SC-7(8)" ] } }, { "key": "email-authentication", "name": "Email authentication & anti-spoofing", "description": "Mail sent in the organization’s name is verifiable, and mail arriving in somebody else’s name is checked. On the SENDING side the organization publishes the records that let a receiver establish that a message claiming to come from one of its domains actually did: a sender policy naming the hosts entitled to send for each domain it owns - including the domains it never sends from, which say exactly that - and a signing key so a message carries a verifiable signature over its own content. Above both sits a published handling policy telling receivers what to do with a message that fails those checks, moved from monitoring to enforcement rather than left permanently in report-only, with the aggregate reports it produces actually read, so a legitimate sender nobody knew about is found before enforcement breaks it. On the RECEIVING side the same checks are performed on inbound mail rather than only offered to others: a message that fails authentication for the domain it claims is quarantined or rejected according to that domain’s published policy, so a forged message from a domain that took the trouble to publish one does not reach an inbox to be judged on how convincing it reads. The domains are inventoried - including the ones registered defensively and the ones a third party sends from on the organization’s behalf - because the unprotected domain is the one an attacker picks, and the records are reviewed when a sending service is added, changed or retired rather than left as they were configured. Phishing is answered by mechanism as well as by authentication, so that a convincing message is not left to the recipient’s judgment: inbound mail is inspected for the links and attachments that carry credential harvesting and malware, links to destinations the organization blocks are rewritten, scrubbed or stripped before delivery rather than after a click, mail that fails inspection is quarantined for somebody trained to judge it, and the same destinations are refused at the browser and at the resolver so that a link arriving by another route is stopped there too.", "crosswalks": { "cis-controls": [ "9.5" ], "pci-dss": [ "5.4" ] } }, { "key": "application-security-requirements", "name": "Application security requirements", "description": "Before an application is built, bought or significantly changed, the security requirements it must meet are identified, written down and approved - so that security is a specification the application is tested against rather than a review it is subjected to afterwards. The requirements are derived from the classification of the information the application will handle, from a threat assessment of how it will be used and exposed, and from the legal, regulatory and contractual duties attached to it. They cover the areas an application fails in: how users and services are identified and authenticated, how authorization decisions are made and enforced on the server side, how sessions are established, protected and ended, how input is validated and output encoded, what is logged and what must never be logged, how errors behave without disclosing internals, what cryptography is used and how its keys are handled, how the application separates one tenant or customer from another, and how a transaction is protected end to end where money or an instruction is involved. Each requirement is written so it can be tested, and it is carried into the acceptance criteria rather than left in a document. For an application bought rather than built, the same requirements are put to the supplier as conditions of purchase and their satisfaction is evidenced before go-live. Three of those requirements are stated concretely because they are the ones most often written as an intention. INPUT VALIDATION: the inputs the organization has defined as needing it are checked for valid syntax, semantics and content before the system accepts and acts on them, with the rules stated per input rather than left to a general instruction to sanitize, and with the behavior on an invalid input decided - rejected, or corrected only where the correction cannot itself change the meaning. ERROR HANDLING: an error message says enough for somebody to take corrective action and no more, disclosing no information that could be used to attack the system - no stack trace, no query, no path, no credential, no internal identifier - and errors are revealed only to the roles authorized to see them. SESSION AUTHENTICITY: the authenticity of a communications session is protected and verified end to end, so a session cannot be hijacked, replayed or injected into once it is established, and a session identifier is invalidated at logout and regenerated on a change of privilege rather than reused. The threat assessment behind the requirements is performed as THREAT MODELING, and at the point where it can still change the design - before the code exists: somebody trained to do it walks the application’s architecture, entry points and access levels, identifies the security design flaws in it and gauges the risk each carries, and those findings become requirements rather than a report.", "crosswalks": { "cis-controls": [ "16.14" ], "iso-27001": [ "A.8.26" ], "nist-800-171": [ "3.13.15" ], "nist-800-53": [ "SC-23", "SI-10", "SI-11" ], "fedramp-rev5-class-c": [ "SC-23", "SI-10", "SI-11" ], "fedramp-rev5-class-d": [ "SC-23", "SI-10", "SI-11" ] } }, { "key": "secure-architecture-principles", "name": "Secure architecture & engineering principles", "description": "The organization writes down the engineering principles its systems are designed to, and applies them to everything it builds or significantly changes rather than to whatever the architect of the day remembers. The principles state positions the design has to answer: defense in depth, so no single control failing exposes the system; least privilege for every identity, service and process; secure defaults, so an unconfigured system is safe rather than open; failing into a secure state rather than an available one; minimizing attack surface by removing rather than protecting what is not needed; validating at each layer rather than trusting a caller because it is internal; separating duties in the design so no single component or person can complete a sensitive action alone; and designing for the assumption that any component may be compromised. Each principle carries enough guidance to be applied by an engineer without asking what it means. Designs are reviewed against the principles at a defined point before build starts, a deviation is recorded and approved with its reason rather than argued informally, and the review reaches systems that are bought or outsourced as well as ones written in-house. The principles are revisited as threats, platforms and technologies change, and the changes are pushed to the teams designing against them. The output is an ARCHITECTURE, not only a set of positions: security and privacy architectures are developed and maintained for the organization’s systems, describing how the requirements are met, how the information is protected through the whole of its life, how privacy risk to individuals is minimized by design, and how the design assumptions and dependencies hold - and they are reconciled with the organization’s enterprise architecture rather than drawn beside it, reviewed and updated as the environment changes, and reflected in the acquisition and procurement decisions taken from them. Four specific separations follow from the principles and are stated so they cannot be argued away. User-facing functionality, including user interfaces and services, is kept physically or logically separate from system management functionality, so an administrative capability is not reachable from the surface every user already has. Unauthorized and unintended transfer of information through SHARED SYSTEM RESOURCES is prevented, so memory, storage, registers, caches and buffers released by one user or process do not deliver residual data to the next. Each executing process is maintained in a separate execution domain, so one process cannot read or modify another’s state. And memory is protected by mechanisms that prevent unauthorized code from executing in it. Two of the principles are stated concretely because they are the ones a design quietly skips. MEDIATION: every operation a user asks for is validated at the point it is acted on rather than trusted because an earlier screen allowed it, and input is subjected to explicit, documented checking for size, data type, and the ranges or formats the operation accepts - the position being that user input is never trusted, including input that arrived by way of the organization’s own front end. REUSE OVER REINVENTION: the security-sensitive components of an application - identity and authentication, authorization, cryptography, audit logging - are built on vetted platform mechanisms, established libraries or services rather than written afresh, and only standardized, currently accepted and widely reviewed cryptographic algorithms are used, because a bespoke implementation of a solved problem is where the implementation errors are.", "crosswalks": { "fedramp-rules-2026": [ "VDR-CSO-DFR" ], "fedramp-rev5-class-d": [ "SA-17", "SC-24", "SC-3", "PL-8", "SC-2", "SC-4", "SC-39", "SI-16" ], "fedramp-20x": [ "KSI-CNA-DFP", "KSI-CNA-MAT", "KSI-CNA-ULN", "KSI-SVC-PRR" ], "cis-controls": [ "16.10", "16.11" ], "iso-27001": [ "A.8.27" ], "nist-800-171": [ "3.13.2", "3.13.3", "3.13.4" ], "nist-800-53": [ "PL-8", "SC-2", "SC-4", "SC-39", "SI-16" ], "fedramp-rev5-class-b": [ "PL-8", "SC-39" ], "fedramp-rev5-class-c": [ "PL-8", "SC-2", "SC-4", "SC-39", "SI-16" ] } }, { "key": "security-testing-in-development", "name": "Security testing in development & acceptance", "description": "Security testing is planned as part of development rather than added before release, and what will be tested, by whom, at which stage and against what pass criteria is decided in advance. The testing performed matches the risk of what is being built and typically combines automated analysis of the code, testing of the running application, analysis of third-party and open-source dependencies for known vulnerabilities and license problems, detection of credentials committed to the repository, review of the deployed configuration, and explicit tests of the application’s own stated security requirements - so a requirement that was written is a test that runs. Testing happens continuously through development where it can be automated, and again before acceptance, in an environment close enough to production that a result means something. Acceptance is conditional on the criteria being met: an unmet criterion is a release decision recorded by a named role with a remediation date, not an omission. Findings are tracked to closure on deadlines set by severity, and are fed back to the developers who can prevent the next one. Testing is repeated for significant change rather than performed once at first release. Test environments and their data are protected and do not expose production information. The severity that drives those deadlines comes from a maintained SEVERITY RATING SYSTEM rather than from the judgment of whoever triages: the ratings and the process for applying them are written down, so two vulnerabilities of the same seriousness are triaged the same way and the most severe are fixed first, and the system states the minimum level of security acceptability for releasing code or an application at all. It is reviewed and updated on a defined cadence.", "crosswalks": { "fedramp-rev5-class-c": [ "SA-11(1)", "SA-11(2)" ], "fedramp-rev5-class-d": [ "SA-11(1)", "SA-11(2)" ], "cis-controls": [ "16.6" ], "iso-27001": [ "A.8.29" ] } }, { "key": "outsourced-development-oversight", "name": "Outsourced development oversight", "description": "Where software is developed by somebody else - an agency, a contractor, an offshore team, or a supplier building to order - the organization directs, monitors and reviews the work rather than receiving it. The security requirements, the secure coding expectations, the architecture principles to be followed, the testing to be performed and the criteria for acceptance are written into the agreement, not raised at delivery. Ownership of the code and of the intellectual property in it, and the licensing of anything third-party included in it, are settled before work starts. The organization retains the right to examine and test what is delivered and to audit the development process behind it, and it exercises that right rather than holding it: evidence of the supplier’s own testing is required and reviewed, and the delivered code and its dependencies are independently examined for vulnerabilities, for components with unacceptable licenses or no support, and for anything that should not be there. The supplier’s developers are subject to screening, confidentiality obligations and access rules equivalent to the organization’s own, and their access to source, environments and data is granted and removed on the same terms. Continuity of the code base - escrow, a full and buildable handover, or the ability to take the work in-house - is addressed at contracting rather than at the end. The supplier is required to run configuration management on the work itself, over the phases the organization names - design, development, implementation, operation - and to say so concretely: which items are under configuration management, how a change to any of them is proposed, justified and documented, that only the changes the organization has approved are implemented, and that security flaws and the flaw resolution process are tracked within the system and reported to a role the organization has named.", "crosswalks": { "fedramp-rev5-class-d": [ "SA-16", "SA-21", "SA-10" ], "iso-27001": [ "A.8.30" ], "nist-800-53": [ "SA-10" ], "fedramp-rev5-class-c": [ "SA-10" ] } }, { "key": "environment-separation", "name": "Separation of development, test and production", "description": "Development, test and production are separated so that work in one cannot reach or affect another except through a controlled path. The separation is real rather than nominal: different systems or clearly separated instances, different network segments, different credentials, and different access lists, so having access to development does not confer access to production. Who may reach production is a smaller and separately authorized set, and the everyday work of building software does not require it. Software moves between environments through a defined promotion path with a record of what moved, when, from which version, and on whose approval; nothing is edited directly in production, and where an emergency fix has to be, it is authorized, recorded and reproduced back into the source afterwards. Compilers, development tools, source code and debugging utilities are not present on production systems. Production data is not copied into a lower environment except under the masking rules, with recorded authorization, and with the copy protected and erased on the same terms as the original. Environments are labeled clearly enough in every interface people use that a destructive action taken in the wrong one is hard rather than easy, and the separation is verified periodically rather than assumed to have survived every change since it was built.", "crosswalks": { "fedramp-rev5-class-d": [ "CM-4(1)" ], "cis-controls": [ "16.8" ], "iso-27001": [ "A.8.31" ] } }, { "key": "test-data-management", "name": "Test information management", "description": "The data used for testing is chosen, protected and disposed of deliberately. Synthetic or purpose-built datasets are the default, because a test does not usually need real people to prove that a system works. Where production data is genuinely required, using it is authorized by a named role against a recorded reason, it is masked, pseudonymized or reduced to the minimum fields the test actually needs before it is copied, and the authorization records what was copied, to where, and until when. A copy carries the protection of its source rather than the protection of the environment it landed in: the same access restrictions, the same encryption, the same logging, and access limited to the testers who need it rather than to everybody with an account in that environment. Copies are erased when the test finishes rather than left as the environment’s new baseline, and a register records which datasets exist in which environment, who authorized each, and when it is due for removal - so the question of where personal data has spread to is answerable. Where the test itself creates data about real people, that output is treated with the same care as the input, and operational data is never left reachable from a test environment’s ordinary credentials.", "crosswalks": { "iso-27001": [ "A.8.33" ] } }, { "key": "audit-testing-safeguards", "name": "Protection of systems during audit testing", "description": "Testing performed against a live system for assurance purposes - an internal or external audit, an assessment, a vulnerability scan, a penetration test, or a supplier’s review - is planned and agreed with the management responsible for that system before it starts, so an assurance activity does not become an availability incident. The agreement covers scope and the systems in and out of it, the methods permitted, when the work runs, and who to contact on both sides if something goes wrong. Access for the test is read-only wherever the objective can be met that way, and where it cannot, what may be changed is stated and the change is reversed and confirmed afterwards. Accounts and credentials issued for the test are created for it, are limited to what it needs, are time-bounded, are logged, and are revoked when it ends. Activity is monitored while it runs, and the operations team knows the test is happening so a real incident during it is still recognized as one. Work likely to affect performance or availability is scheduled outside peak periods or run against a copy. Data extracted during the test is treated according to its classification, is held only as long as the report needs it, and is returned or destroyed at the end - and the plan says in advance what happens, and who decides, if the test degrades the service.", "crosswalks": { "iso-27001": [ "A.8.34" ] } }, { "key": "system-use-notification", "name": "System use notification", "description": "Before access is granted, a system displays a notice that tells the person what they are connecting to and on what terms, and the notice is a control rather than decoration. It is written once, approved by the roles accountable for it - legal, privacy and security together, because it is the point at which the organization states its position - and applied consistently to every path into the system, including the ones people forget: the remote access gateway, the administrative console, the terminal session, the application login page and the device sign-in screen. It states that use of the system may be monitored, recorded and subject to audit; that unauthorized use is prohibited and carries consequences the organization will actually pursue; and that continuing to sign in is how the user accepts those terms. The wording is consistent with the privacy and security notices the applicable laws, regulations, policies and standards require, so it is not a slogan the organization has invented for itself. The notice stays on screen until the user acknowledges it and takes an explicit action to log on, rather than flashing past. For a system the public can reach, the same information is displayed before further access is granted, references to monitoring and recording are written to match what is actually permitted for that kind of system, and the notice describes the uses of the system the organization authorizes so a visitor can tell what is allowed.", "crosswalks": { "nist-800-171": [ "3.1.9" ], "nist-800-53": [ "AC-8" ], "fedramp-rev5-class-b": [ "AC-8" ], "fedramp-rev5-class-c": [ "AC-8" ], "fedramp-rev5-class-d": [ "AC-8" ] } }, { "key": "wireless-network-security", "name": "Wireless network security", "description": "Wireless access to the organization’s systems is a decided arrangement rather than an emergent one. Each TYPE of wireless access it permits - the corporate network, a guest network, a point-to-point link, a device-to-device pairing, a wireless management interface on a piece of equipment - carries written configuration requirements, connection requirements and implementation guidance, and is authorized as a type before any connection is allowed under it. Access is protected by authentication of the user or the device together with encryption, using mechanisms current enough to still be worth having, and the network is designed so that a client on it is not thereby inside anything it should not reach. What is broadcast is decided too: the identifiers, the coverage that spills beyond the premises, and whether a network needs to be discoverable at all. Rogue and unauthorized access points are looked for rather than reported by accident, and what happens when one is found is decided in advance. Wireless capability that the organization does not intend to use is disabled in system components before they are issued and deployed - the radio built into a server, a printer, a camera, an industrial controller or a laptop that will never need it is turned off at build rather than left enabled because nobody configured it. Guest and untrusted wireless is separated from everything else, and the arrangement is reviewed on a cadence and when the estate or the technology changes. VENDOR DEFAULTS on the wireless estate are replaced before the network carries anything: the default encryption keys and passphrases, the default administrative credentials on access points and controllers, the default network names, and the default management community strings are changed at commissioning, and changed again when somebody who knew them leaves. The search for what nobody authorized is scheduled rather than occasional: a current list of the access points the organization has authorized is maintained with the location and the owner of each, a sweep for wireless access points runs on a stated recurring cadence and after a change to the estate, and anything found that is not on the list is investigated and then removed or authorized as a recorded decision rather than left because it works.", "crosswalks": { "fedramp-rev5-class-d": [ "AC-18(4)", "AC-18(5)", "SI-4(14)", "AC-18", "AC-18(1)", "AC-18(3)" ], "pci-dss": [ "2.3", "11.2" ], "nist-800-171": [ "3.1.16", "3.1.17" ], "nist-800-53": [ "AC-18", "AC-18(1)", "AC-18(3)" ], "fedramp-rev5-class-b": [ "AC-18" ], "fedramp-rev5-class-c": [ "AC-18", "AC-18(1)", "AC-18(3)" ] } }, { "key": "mobile-device-security", "name": "Mobile device security", "description": "Phones, tablets and other mobile devices the organization controls are governed as a class of their own, because they leave the building by design. Configuration requirements, connection requirements and implementation guidance are written for them - what the device must be running, what settings are enforced, what it may connect to, what may be installed on it, and what is required of it specifically when it is outside a controlled area, where the assumptions that hold in an office do not. Connecting a mobile device to the organization’s systems is authorized rather than assumed: the device is enrolled and identifiable, the authorization is recorded against a person, and an unenrolled device does not obtain access because somebody knows a password. The information on the device is protected by encryption - full-device encryption, or a managed container holding the organization’s data separately from the person’s - so that the confidentiality and integrity of what it holds survive the device being lost, and the organization can remove its data without taking everything else with it. Loss and theft are planned for rather than reacted to: reporting is immediate and the route is known, and remote lock and wipe are configured and tested rather than assumed to be available. Where a personally owned device is permitted, the conditions are stated in writing and accepted before access, including what the organization may do to the device, what it may see, and what happens to its information when the arrangement ends. The estate is reviewed for devices that have stopped checking in, stopped receiving vendor updates, or left with somebody who has gone. The class covered is the PORTABLE end-user device rather than the handset alone: a laptop travels on the same terms and carries the same requirements. Repeated failure to authenticate locally locks the device automatically once a defined threshold of consecutive failed attempts is reached, so a device in somebody else’s hands cannot be worked at indefinitely, and that threshold is set rather than left to the platform default. Where the device supports a separate enterprise workspace or work profile, one is used, so the organization’s applications and data sit in a container it governs and the person’s own applications and data sit outside it.", "crosswalks": { "cis-controls": [ "4.10", "4.11", "4.12" ], "nist-800-171": [ "3.1.18", "3.1.19" ], "nist-800-53": [ "AC-19", "AC-19(5)" ], "fedramp-rev5-class-b": [ "AC-19" ], "fedramp-rev5-class-c": [ "AC-19", "AC-19(5)" ], "fedramp-rev5-class-d": [ "AC-19", "AC-19(5)" ] } }, { "key": "public-information-review", "name": "Review of publicly posted information", "description": "Publishing information where anybody can read it is treated as a disclosure decision, and somebody is accountable for it. The individuals authorized to make information publicly accessible are designated by name or role rather than being whoever holds the credentials to the website, the app listing, the code repository, the social account or the document portal. Those individuals are trained for the specific failure this control exists to prevent: that nonpublic information ends up on a public surface - personal data, security detail, internal identifiers, customer names, unreleased plans, credentials or keys embedded in a file, metadata and revision history inside a document, and anything the organization’s classification scheme says does not leave. Proposed content is reviewed before it is posted, against stated criteria rather than a general instruction to be careful, and the review is recorded so it can be shown to have happened. Publication is not the end of it: what is already published is re-reviewed on a defined cadence, because a page that was safe when written can be made unsafe by what was published beside it later, and anything nonpublic that is found is removed - with the removal treated as a potential incident and assessed as one rather than quietly corrected. The scope covers every public surface the organization actually operates, including the ones not owned by the marketing function. Public statements made during and after an incident fall inside this control rather than outside it: an update on incident recovery goes out through the designated individuals, on the channels the organization has approved for it, against messaging agreed in advance with the legal, security and communications roles - so what is said publicly about an incident is reviewed on the same terms as everything else the organization publishes, at the moment that is hardest to do.", "crosswalks": { "fedramp-rules-2026": [ "SCG-CSO-PUB", "VER-RPT-NID" ], "nist-csf": [ "RC.CO-04" ], "nist-800-171": [ "3.1.22" ], "nist-800-53": [ "AC-22" ], "fedramp-rev5-class-b": [ "AC-22" ], "fedramp-rev5-class-c": [ "AC-22" ], "fedramp-rev5-class-d": [ "AC-22" ] } }, { "key": "system-authorization", "name": "Authorization to operate a system", "description": "A system does not go into service because it is ready; it goes into service because a senior official accountable for the risk has said it may. That official is named for the system, and a senior official is named for the COMMON CONTROLS other systems inherit - the shared platform, identity service, network, logging and facility controls a team does not implement for itself - so the controls somebody else runs on your behalf are authorized by somebody rather than assumed. Before operations begin, the official accepts the common controls the system will inherit, considers the system security and privacy plan, the results of the control assessment and the outstanding weaknesses with their remediation plan, and authorizes the system to operate, records the decision with its date and any conditions attached, or refuses it. The official responsible for common controls authorizes their use for inheritance on the same terms. An authorization is not permanent: it is reviewed and updated on a defined cadence and on the events the organization has decided require it - a significant change to the system or its environment, a serious incident, or a material change in the risk - so an approval given years ago against a system that no longer exists is not still standing. The authorization decisions, and the evidence they rested on, are retained. Where the system is an AI system, the same decision answers two further questions before it is given: whether the system actually achieves its intended purpose and the objectives stated for it, and whether its development or deployment should proceed at all - so \"it works well enough to authorize\" is a finding on the record rather than an assumption behind it, and not proceeding is one of the answers available.", "crosswalks": { "nist-800-53": [ "CA-6" ], "nist-ai-rmf": [ "MANAGE-1.1" ], "fedramp-rev5-class-b": [ "CA-6" ], "fedramp-rev5-class-c": [ "CA-6" ], "fedramp-rev5-class-d": [ "CA-6" ] } }, { "key": "external-identity-acceptance", "name": "External and federated identity acceptance", "description": "People and processes the organization did not issue an account to still reach its systems - customers, partners, contractors on their own employer’s credential, citizens, and the automated processes acting for any of them - and they are identified and authenticated as rigorously as internal users rather than being trusted for arriving through a different door. Each such user, and each process acting on their behalf, is uniquely identified so an action traces to one party. Where the organization accepts a credential issued by somebody else, it accepts only credentials from issuers it has assessed and approved, VERIFIES THEM ELECTRONICALLY against the issuer rather than accepting the assertion at face value - checking the signature, the validity period and the revocation status at the moment of use - and applies the same test to a credential presented by a party from another organization or agency as to one from its own federation partner. Which external authenticators are accepted is a maintained list rather than an implicit set: each entry names the issuer, the assurance level it satisfies, the standard or profile it conforms to, and the review date, and an authenticator that does not meet the applicable standard is refused. Where an identity-management profile applies to a class of external user, the organization conforms to it rather than inventing its own attribute set, so an assertion means the same thing on both sides. Products used to implement these capabilities are drawn from the approved list the applicable standard maintains, where one exists, rather than assembled from whatever integrates. External identities are reviewed and removed on the same lifecycle terms as internal ones. The ASSERTION itself is protected as well as verified: it travels over a channel that authenticates both ends and prevents it being read or altered in transit, it is bound to the session and the audience it was issued for so it cannot be replayed somewhere else, and its lifetime is short enough that a captured assertion has expired before it is worth anything.", "crosswalks": { "nist-csf": [ "PR.AA-04" ], "nist-800-53": [ "IA-2(12)", "IA-8", "IA-8(1)", "IA-8(2)", "IA-8(4)", "SA-4(10)" ], "fedramp-rev5-class-b": [ "IA-2(12)", "IA-8", "IA-8(1)", "IA-8(2)", "IA-8(4)", "SA-4(10)" ], "fedramp-rev5-class-c": [ "IA-2(12)", "IA-8", "IA-8(1)", "IA-8(2)", "IA-8(4)", "SA-4(10)" ], "fedramp-rev5-class-d": [ "IA-2(12)", "IA-8", "IA-8(1)", "IA-8(2)", "IA-8(4)", "SA-4(10)" ] } }, { "key": "cryptographic-key-management", "name": "Cryptographic key management", "description": "Wherever the organization uses cryptography, the keys behind it are managed to written requirements rather than to whatever the tool defaulted to - because a strong algorithm on a badly held key protects nothing. The requirements state, for each class of key, how it is generated and to what strength, how it is distributed to the parties that need it and how they prove they are entitled to it, where and how it is stored, how it is used and by what, how often it is rotated, how it is revoked and destroyed when it is compromised or retired, and how it is recovered or escrowed where the information would otherwise become unreadable. A key’s life is bounded and its retirement is planned, so rotation is a scheduled act rather than a crisis. Private keys are held so that only the entity they identify can use them, and access to them is enforced technically rather than by convention. PUBLIC KEY CERTIFICATES are issued under a certificate policy the organization has approved, or obtained from a service provider it has approved, and only trust anchors it has approved are present in the trust stores and certificate stores it manages - a store nobody has curated is a list of parties allowed to impersonate anybody. Where the organization relies on public key authentication, an authenticated certificate is mapped to the account of the individual or group it belongs to rather than accepted as an identity in itself, certificates are validated by building and verifying a certification path to an accepted trust anchor including a check of revocation status, and revocation data is cached locally so that path discovery and validation still work when the source of that data cannot be reached. Authentication to the cryptographic modules themselves - the hardware security module, the key vault, the token, the software module - uses mechanisms that satisfy the laws, standards and guidelines that apply to it, rather than a shared operator password. Key material is inventoried, its owner recorded, and its use logged, so the question of what a compromised key opened is answered from a record. Where the keys protect payment or account data the storage rules are tighter and are stated rather than inferred: keys are held in the fewest locations and by the fewest custodians the operation can run with, a key that encrypts another key is protected at least as strongly as the key it wraps and is kept apart from it, key material at rest is held only in a form the organization has approved in advance - inside a secure cryptographic device, split into components or shares that no single custodian holds in full, or encrypted under a separate key-encrypting key - and every custodian acknowledges the responsibilities of the role in writing before taking it on.", "crosswalks": { "fedramp-rules-2026": [ "CMU-CSO-CMD" ], "fedramp-rev5-class-d": [ "CM-3(6)", "SC-12(1)", "IA-5(2)", "IA-7", "SC-12", "SC-17" ], "fedramp-20x": [ "KSI-IAM-SNU", "KSI-SVC-ASM" ], "pci-dss": [ "3.6", "3.7" ], "nist-800-171": [ "3.13.10" ], "nist-800-53": [ "IA-5(2)", "IA-7", "SC-12", "SC-17" ], "fedramp-rev5-class-b": [ "IA-7", "SC-12" ], "fedramp-rev5-class-c": [ "IA-5(2)", "IA-7", "SC-12", "SC-17" ] } }, { "key": "security-plan-and-baseline", "name": "System security plan & control baseline", "description": "Each system the organization runs has a plan that says what it is and how it is protected, and the plan is a working document rather than an artifact produced for an assessment. It defines the system’s components and its boundary; describes what the system is for in terms of the business processes it serves; names the individuals who fill its roles; identifies the types of information it processes, stores and transmits and the security categorization it carries, with the reasoning behind that categorization; describes the operational environment and the dependencies on and connections to other systems; sets out the threats of particular concern; records the results of a privacy risk assessment where personal data is involved; gives an overview of the security and privacy requirements; and describes the controls in place or planned to meet them, together with the risk determinations behind the architecture and design decisions and the activities that need planning or coordination with other parties. It is consistent with the organization’s wider architecture rather than written in isolation. THE CONTROL BASELINE is part of that plan and is chosen deliberately: the organization selects a baseline appropriate to the system - from a recognized catalog, a sector overlay, or its own defined sets - as the starting point rather than assembling controls one at a time, and then TAILORS it, recording each tailoring action and the rationale for it: a control scoped out because the system does not have the thing it protects, a parameter set to a specific value, a compensating control substituted, an overlay applied. A tailoring decision without a recorded reason is not a tailoring decision. The plan is reviewed and approved by the official accountable for the system before it is implemented, distributed to the parties who need it with changes communicated to them, reviewed on a defined cadence, updated when the system or its environment changes or when implementation and assessment expose a problem, and protected from unauthorized disclosure and modification - because a current plan is a map of where everything valuable is.", "crosswalks": { "nist-800-171": [ "3.12.4" ], "nist-800-53": [ "PL-2", "PL-10", "PL-11" ], "fedramp-rev5-class-b": [ "PL-2", "PL-10", "PL-11" ], "fedramp-rev5-class-c": [ "PL-2", "PL-10", "PL-11" ], "fedramp-rev5-class-d": [ "PL-2", "PL-10", "PL-11" ] } }, { "key": "privacy-program-accountability", "name": "Data protection accountability program", "description": "The organization can show, not merely assert, that its handling of personal data meets the principles it is bound by: for each one - lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; and integrity and confidentiality - it names the measure that gives effect to it and the record that would demonstrate it to somebody who asked, so the answer to \"prove it\" is a document rather than a description. The measures are technical and organizational together, and how far they go is decided against the nature, scope, context and purposes of the processing and against the likelihood and severity of the risk it poses to the people whose data it is - a low-risk mailing list and a large-scale profiling operation are not held to the same set, and the reasoning that put a given activity in one place rather than the other is written down. Accountability has a named owner, a documented program of work, and one place the evidence lives. The whole set is reviewed and updated where the review shows it is needed: when the processing changes, when a new risk appears, when an incident or an audit exposes a weakness, and on a stated cadence in the absence of any of those - so what is in place tracks the processing rather than the date somebody last wrote it down.", "crosswalks": { "gdpr": [ "Art.5(2)", "Art.24(1)" ], "pipeda": [ "4.1.4" ] } }, { "key": "lawful-basis-determination", "name": "Lawful basis for processing", "description": "Every processing activity has a lawful ground identified and recorded before it starts, chosen from the grounds the law makes available rather than assumed after the fact - the individual’s consent, necessity for a contract with them or for steps taken at their request before entering one, a legal obligation on the organization, someone’s vital interests, a task carried out in the public interest or under official authority, or legitimate interests pursued by the organization or by a third party. Where legitimate interests is the ground, the interest is stated, the processing is tested as actually necessary to it, and the interest is weighed against the interests, rights and freedoms of the people affected - with particular weight where any of them is a child - and that assessment is written down rather than reached in conversation; a public authority may not rely on legitimate interests at all for the processing it carries out in performing its tasks. Where consent or a contract is the ground, what makes it available is recorded too, so a later reader can see why the ground applies to this activity and not merely that somebody selected it. The ground is revisited when the activity changes, when the ground stops being available - consent withdrawn, a contract ended, an obligation repealed - and on the same cadence as the register of processing activities; an activity found to have no ground is stopped rather than allowed to run while the question is settled. Where personal data feeds an AI system - as training data, as tuning data, or as an input at inference - that use is treated as a processing activity in its own right and given its own recorded ground, rather than inheriting the ground recorded for the activity the data was first collected under. The rights the people concerned hold over that processing are routed into the same procedure that serves every other activity, so a request is not refused on the basis that the data has been absorbed into a model.", "crosswalks": { "gdpr": [ "Art.6(1)" ], "ai-governance-essentials": [ "DA.3" ], "pipeda": [ "5(3)", "7(1)", "7(2)" ] } }, { "key": "special-category-data-handling", "name": "Special category and criminal offense data", "description": "Data of the kinds the law singles out for extra protection is found wherever the organization holds it - data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, genetic data, biometric data used to identify a person uniquely, data concerning health, and data concerning a person’s sex life or sexual orientation - and it is treated as prohibited by default: nobody processes it because a system happens to permit it, and where it appears in a free-text field, an attachment, an uploaded document or an inference drawn from other data, it is treated exactly as if it had been collected deliberately. Processing proceeds only where one of the narrow conditions that lift the prohibition has been established, recorded against the activity and can be evidenced afterwards - explicit consent for one or more specified purposes, an employment or social-security obligation authorized by law or a collective agreement carrying safeguards, vital interests where the person cannot give consent, the internal processing of a not-for-profit body about its own members and regular contacts, data the person has manifestly made public, bringing or defending legal claims, substantial public interest on a legal basis, health or social care and its management, public health, or archiving, research and statistics under the safeguards those purposes require. Where the condition depends on a law or a collective agreement, the instrument relied on is named rather than the category cited. Where the ground is a health or social-care purpose, the data is processed by or under the responsibility of a person bound by an obligation of professional secrecy, and the organization can say who that person is and what binds them. Data about criminal convictions, offenses and related security measures carries a separate rule and is treated separately: it is processed only under the control of official authority, or where a law authorizes it and provides appropriate safeguards for the people it concerns, and the organization keeps no comprehensive register of criminal convictions unless it is an official authority. Where no condition can be established for a category of this data, the processing does not begin, and any already held is deleted or put beyond use rather than left in place pending a decision.", "crosswalks": { "gdpr": [ "Art.9(1)", "Art.9(2)", "Art.9(3)", "Art.10" ] } }, { "key": "data-subject-request-procedure", "name": "Data subject request procedure & deadlines", "description": "A written procedure governs what happens between a request about someone’s own personal data arriving and the answer going out, and it is owned by a named role rather than by whoever opened the inbox. The action taken is reported to the person without undue delay and in any event within one month of receiving the request. That month may be extended by two further months where the request is complex or where several have arrived together - but only if the person is told of the extension and the reason for it inside the first month, so an extension is a communication rather than a silence. Where the organization decides to take no action, it says so within that same month, gives the reasons, and tells the person that they may lodge a complaint with a supervisory authority and seek a judicial remedy, so a refusal always carries the route to challenge it. Information and action on a request are provided free of charge in the ordinary case. A request that is manifestly unfounded or excessive - a repetitive one is the usual example - may instead attract a reasonable fee based on the administrative cost of answering it, or be refused outright, but the reasoning that gives the request that character is written down before either step is taken, because the burden of demonstrating it sits with the organization and not with the person asking. Where the organization genuinely cannot identify the person from the data it holds, it tells them so where it is possible to do so, and explains that the access, rectification, erasure, restriction, notification and portability rights cannot be acted on unless they supply information that enables identification - rather than refusing without explanation, or manufacturing an identification it does not have. Where a request arrives electronically the answer goes back electronically unless the person asks otherwise. Every request is logged with the date it arrived, the deadline that applies to it, the decision, the date of the reply and who made it, so the clock is a tracked commitment rather than an intention.", "crosswalks": { "gdpr": [ "Art.11(2)", "Art.12(3)", "Art.12(4)", "Art.12(5)" ], "pipeda": [ "8(1)", "8(3)", "8(4)", "8(6)", "8(7)" ] } }, { "key": "privacy-information-notice", "name": "Information given when data is collected from the individual", "description": "At the moment personal data is taken directly from a person, they are given a complete set of information about what is about to happen to it, in one place and in language they can follow. It identifies the organization and how to contact it, and its representative where it has one; gives the contact details of the data protection officer where one is designated; states each purpose the data is intended for and the legal ground relied on for each; states the legitimate interests pursued by the organization or by a third party wherever legitimate interests is that ground; names the recipients or the categories of recipient, if there are any; and, where the data is intended to go to another country or to an international organization, says so and says whether a formal adequacy decision covers the destination or which safeguards are relied on in its absence, together with how to obtain a copy of those safeguards or where they have been made available. Because fair and transparent processing needs more than that, the same notice also gives the period the data will be stored for or, where that cannot be stated, the criteria used to fix it; the rights to request access, rectification, erasure and restriction, to object, and to data portability; the right to withdraw consent at any time without affecting the lawfulness of what was done before the withdrawal, wherever consent is the ground; the right to lodge a complaint with a supervisory authority; whether providing the data is a statutory or contractual requirement or is necessary to enter into a contract, whether the person is obliged to provide it, and what the consequences of not providing it are; and the existence of any decision-making carried out solely by automated means, profiling included, with meaningful information about the logic involved and about the significance and envisaged consequences of it for that person. The notice is delivered at the point of collection rather than left somewhere to be found afterwards, and each version is dated and retained so the organization can show what a particular person was actually told. Where the data is later to be used for a purpose other than the one it was collected for, the person is told about that other purpose, together with the further information above that goes with it, before the new use starts rather than after.", "crosswalks": { "gdpr": [ "Art.13(1)", "Art.13(2)", "Art.13(3)" ], "pipeda": [ "4.2.3", "4.3.2" ] } }, { "key": "indirect-collection-notice", "name": "Information given when data is obtained from somewhere else", "description": "Where personal data reaches the organization from somewhere other than the person it is about - a data provider, a partner, a public source, another part of a group, an inference drawn from something else - the same duty of transparency applies, and it is discharged deliberately because there is no collection moment at which to discharge it by default. The information given identifies the organization and how to contact it, and its representative where it has one; gives the contact details of the data protection officer where one is designated; states the purposes and the legal ground; states the categories of personal data concerned, which matters here because the person did not hand them over and does not know what arrived; names the recipients or categories of recipient; and, where the data is intended to go to another country or an international organization, says so with whether an adequacy decision covers the destination or which safeguards are relied on instead and how to obtain a copy of them. It also gives the retention period or the criteria that set it; the legitimate interests pursued where that is the ground; the rights of access, rectification, erasure, restriction, objection and portability; the right to withdraw consent where consent is the ground; the right to complain to a supervisory authority; the source the data came from and whether that source was publicly accessible; and the existence of any solely automated decision-making, profiling included, with meaningful information about the logic and about its significance and envisaged consequences for the person. Timing is fixed rather than left to convenience: within a reasonable period after the data is obtained and at the latest within one month, or - if it comes sooner - at the first communication with that person, or at the first disclosure of the data to another recipient. Before the data is used for a purpose other than the one it was obtained for, the person is told about that other purpose and the further information that goes with it. The notice is not owed where the person already has the information, where giving it is impossible or would take disproportionate effort, where a law expressly provides for the obtaining or disclosure and protects the person’s interests, or where the data must stay confidential under a professional-secrecy obligation - but the organization records which exemption it relied on and why, and where the reason is disproportionate effort or that notifying would defeat a research, archiving or statistical purpose it takes other measures to protect the person’s rights and freedoms, including making the information publicly available rather than leaving nothing in its place.", "crosswalks": { "gdpr": [ "Art.14(1)", "Art.14(2)", "Art.14(3)", "Art.14(4)", "Art.14(5)" ] } }, { "key": "access-request-fulfillment", "name": "Fulfilling an access request", "description": "When someone asks for their personal data, what goes back is a copy of the data actually undergoing processing, assembled from the systems that hold it rather than from whichever one was easiest to export. Where the request arrives by electronic means the copy is provided in a commonly used electronic form, unless the person has asked for something else. The first copy is free; a reasonable fee based on administrative cost may be charged for further copies the same person asks for, and the basis of that fee is stated rather than improvised. Where any of the data has been transferred to another country or to an international organization, the response tells the person which appropriate safeguards protect that transfer, so a transfer disclosed in the abstract in a privacy notice is made concrete for their own data. Before anything is released it is reviewed so that providing it does not adversely affect the rights and freedoms of other people: personal data about somebody else, material a third party holds rights in, and content protected by an obligation of confidence are redacted or withheld, and the decision to withhold is recorded with its reason and the rest of the response is still provided - a third party in the file is not a reason to refuse the request. Who assembles a response, who reviews it before release, and how it is delivered securely to the person who asked are all fixed in advance rather than decided per request. THIRD-PARTY INFORMATION is handled by severance rather than by refusal. Where giving access would likely reveal personal information about somebody else, that material is not released; where it is severable from the record it MUST be severed and the remainder given to the person, so severance is the required step rather than one option beside refusing outright or releasing in full. The restriction falls away where the third party consents to the access, or where the person needs the information because an individual’s life, health or security is threatened. THE GROUNDS FOR REFUSING are a closed list rather than a judgement call, and the list is written down where the people answering requests can see it: information protected by solicitor-client privilege, by the professional secrecy of advocates and notaries, or by litigation privilege; information whose release would reveal confidential commercial information; information whose release could reasonably be expected to threaten the life or security of another individual; information collected without knowledge or consent because seeking consent would have compromised its availability or accuracy and the collection was reasonable for investigating a breach of an agreement or a contravention of law; information generated in the course of a formal dispute resolution process; and information created for the purpose of making a disclosure under public-servant whistleblower-protection legislation, or in the course of an investigation into such a disclosure. That is the whole list, so “commercially sensitive”, “too burdensome” and “internal” are not grounds. For the confidential-commercial and life-or-security cases severance applies again: the protected material is taken out and the rest is released. Every ground is overridden where the person needs the information because an individual’s life, health or security is threatened. Where the refusal rests on the investigation ground, the privacy regulator is notified of it IN WRITING, including whatever further information the regulator specifies - that ground alone carries a reporting duty, and it is performed by the same procedure that issues the refusal rather than remembered afterwards. A REQUEST ABOUT DISCLOSURES TO A GOVERNMENT INSTITUTION is a sequence whose order cannot be rearranged, and the people who answer requests are taught to recognize one before they start drafting. Where the person asks to be informed about a disclosure the organization made to a government institution - to comply with a subpoena, warrant or court order, on an institution’s request citing national security or law enforcement, under the money-laundering and terrorist-financing reporting requirement, or on the organization’s own initiative - or asks about the existence of any information relating to such a disclosure, subpoena, warrant, order or request, or asks for access to that information, then: the organization NOTIFIES the institution concerned, in writing and without delay, that the request has been made; it WAITS, responding to the person no earlier than the day the institution states its position or thirty days after the institution was notified, whichever comes first, that being the period the institution has to say whether it objects; and if the institution does object, the organization REFUSES the request to the extent it relates to being informed about the disclosure or to the information about it, NOTIFIES the privacy regulator of that refusal in writing and without delay, and then SAYS NOTHING FURTHER - it does not disclose to the person the information it holds about the disclosure or the request, nor that it notified the institution, nor that it notified the regulator, nor that the institution objects. The last step is the one an access process built for transparency breaks by default, so it is written into the procedure explicitly: a “we can neither confirm nor deny” line that appears only where there is something to deny, an automatic law-enforcement entry in a response template, and a disclosure log the person can read will each give it away.", "crosswalks": { "gdpr": [ "Art.15(2)", "Art.15(3)", "Art.15(4)" ], "pipeda": [ "4.9.1", "4.9.4", "9(1)", "9(2.2)(a)", "9(2.2)(b)", "9(2.4)(a)", "9(2.4)(b)", "9(2.4)(c)", "9(3)", "9(5)", "10" ] } }, { "key": "erasure-and-restriction", "name": "Erasure follow-through & restriction of processing", "description": "Where the organization has made personal data public and is then obliged to erase it, erasing its own copy is not the end of the duty: taking account of the technology available and what it would cost to use, it takes reasonable steps - technical measures included - to tell the other controllers now processing that data that the person has asked for the erasure of any links to it and of any copy or replication of it. Who sends those messages, to whom, and what record is kept of having sent them is decided in advance, because the step is easy to intend and easy to skip. Separately, processing is restricted rather than stopped or continued in four situations the person can invoke: while the accuracy of data they contest is being verified, for as long as verification takes; where the processing is unlawful and they would rather have it restricted than erased; where the organization no longer needs the data but they need it to bring or defend a legal claim; and while an objection they have made is being assessed. A restriction is enforced by the systems rather than by asking colleagues not to look - the records are flagged, moved, or made unavailable to normal processing, and access is withdrawn - so that beyond simply storing it, restricted data is processed only with the person’s consent, for legal claims, to protect the rights of another person, or for reasons of important public interest. Before a restriction is lifted, the person who obtained it is told that it is being lifted, and told before rather than after.", "crosswalks": { "gdpr": [ "Art.17(2)", "Art.18(1)", "Art.18(2)", "Art.18(3)" ] } }, { "key": "data-portability", "name": "Data portability", "description": "Where the organization processes personal data by automated means on the basis of the person’s consent or of a contract with them, that person can get back the data they themselves provided, in a structured, commonly used and machine-readable format - an export somebody else’s system can actually read, not a rendered document or a screenshot bundle. Which data counts as provided by the person is worked out and written down in advance: what they entered, and what their use of the service generated as observed data, as distinct from what the organization inferred or derived about them. They can pass that export to another organization without the first one obstructing it - no contractual barrier, no artificial format, no delay used as friction - and where it is technically feasible they can require the data to be sent directly from one organization to the other, in which case the transmission route and how the receiving party is authenticated are settled beforehand rather than improvised. Acting on a portability request must not adversely affect the rights and freedoms of other people, so data about somebody else caught up in the person’s own records is handled before the export leaves, and the decision about it is recorded.", "crosswalks": { "gdpr": [ "Art.20(1)", "Art.20(2)", "Art.20(4)" ] } }, { "key": "objection-handling", "name": "Objection & direct marketing opt-out", "description": "An objection to direct marketing is absolute and is treated that way: there is no balancing test, no request for a reason and no retention of the person on a list pending review. Once someone objects, their personal data is no longer processed for direct marketing at all - which reaches the profiling done to target that marketing as well as the sending of it - and the suppression is applied where the sending happens, in every channel and every tool that could send, rather than as a flag in one system that another later overwrites from an import. The right to object is brought explicitly to the person’s attention at the latest at the first communication with them, and it is presented clearly and separately from the rest of what they are being told rather than folded into a paragraph of terms. Where the organization offers an online service, the person can exercise the right by automated means using technical specifications - a machine-readable signal or control the service honors, not only a form somebody has to fill in. Where personal data is processed for scientific or historical research or for statistical purposes, a person may object on grounds relating to their particular situation, and that objection is assessed and acted on unless the processing is necessary for the performance of a task carried out for reasons of public interest. Objections are logged with what was objected to, when, and what was done, so that suppression can be demonstrated and so a re-import cannot quietly undo it.", "crosswalks": { "gdpr": [ "Art.21(2)", "Art.21(3)", "Art.21(4)", "Art.21(5)", "Art.21(6)" ] } }, { "key": "automated-decision-safeguards", "name": "Safeguards for solely automated decisions", "description": "The organization knows where a decision about a person is taken by automated processing alone, profiling included, and whether that decision produces a legal effect for them or affects them in a similarly significant way - credit, employment, pricing, eligibility, access to a service, a suspension. Those decisions are inventoried rather than discovered when somebody complains, and a person has the right not to be subject to one unless it is necessary for entering into or performing a contract with them, is authorized by a law that lays down safeguards, or rests on their explicit consent. Where such a decision is made because a contract requires it or because the person explicitly consented, safeguards for their rights, freedoms and legitimate interests are in place and are usable: at a minimum they can obtain human intervention from someone who has the authority and the information to change the outcome rather than to explain it, they can put their own point of view, and they can contest the decision - with a route to do all three that is published with the decision rather than buried, and a record of what happened when they did. Special category data is not used as a basis for such a decision unless the person has given explicit consent or the processing is necessary for reasons of substantial public interest under a law, and in either case suitable safeguards for their rights, freedoms and legitimate interests are in place. Where the decision is one the organization has decided not to automate solely, the human step is real - somebody with authority considers the case and can reach a different answer - rather than a rubber stamp over the model output.", "crosswalks": { "gdpr": [ "Art.22(1)", "Art.22(3)", "Art.22(4)" ] } }, { "key": "data-protection-by-design", "name": "Data protection by design & by default", "description": "Data protection is settled when the means of processing are decided, not audited afterwards: a new system, feature, integration or supplier arrangement is designed against the data-protection principles, and the measures chosen to give effect to them - pseudonymization being the example the law itself gives, alongside minimizing what is collected at all, separating identifiers from the rest, shortening what is kept, and encrypting what remains - are built into the processing rather than layered over it later. How far those measures go is decided against the state of the art, what implementing them costs, and the nature, scope, context and purposes of the processing together with the likelihood and severity of the risk to the people affected; the reasoning is recorded at the point of the design decision, so a later reader can see what was weighed. The same measures are kept in place while the processing runs, not only at launch. Separately, defaults do the work rather than the settings page: by default only the personal data necessary for each specific purpose is processed, and that applies to how much is collected, how far it is processed, how long it is stored and who can reach it. In particular, no default makes personal data accessible to an indefinite number of people without the person themselves acting - a new record, workspace, profile, share or upload starts closed, and it is the person who opens it. Defaults are reviewed when a feature changes, because a default that was correct at launch is the thing a later release quietly widens.", "crosswalks": { "gdpr": [ "Art.25(1)", "Art.25(2)" ] } }, { "key": "joint-controller-arrangements", "name": "Joint controller arrangements", "description": "Where the organization and another party genuinely decide together why and how personal data is processed - a co-branded service, a shared platform, a joint research program, a referral arrangement in which both parties use what they learn - that is recognized as joint control rather than filed as a supplier relationship, and it is settled in a written arrangement before the processing starts. The arrangement determines, transparently and specifically, which of them discharges which obligation: who answers a request from an individual and inside whose deadline, who gives the information owed at collection and where data was obtained indirectly, who notifies a breach, who holds the record of the activity, and who deals with the supervisory authority. It may name a single contact point for individuals, and where it does, that contact point is published rather than held internally. The arrangement reflects what the parties actually do towards the people whose data it is, rather than allocating a duty to whichever party would rather not perform it, and it is revisited when the roles change. Its essence - who does what, and whom to approach - is made available to those people in language they can act on, not merely recited in a contract they never see. Whatever the arrangement says between the parties, the organization honors an individual’s rights when they are exercised against it, and does not redirect the person to the other party as a way of not answering; where the other party is better placed to act, the organization says so, passes the request on and stays answerable for the outcome.", "crosswalks": { "gdpr": [ "Art.26(1)", "Art.26(2)", "Art.26(3)" ] } }, { "key": "eu-representative", "name": "Representative in the Union", "description": "An organization that has no establishment in the Union but is caught by the Regulation because it offers goods or services to people there or monitors their behavior there designates a representative in the Union, and does it in writing - a signed appointment naming the representative, not an entry on a website. Whether the duty applies is a decision the organization makes deliberately and records: it does not apply where the processing is occasional, does not include large-scale processing of special category or criminal offense data, and is unlikely to result in a risk to people’s rights and freedoms, and it does not apply to a public authority - so the assessment against those conditions is the evidence that no representative is needed, rather than the absence of one. Where a representative is required, it is established in one of the Member States where the people whose data is processed for the offering of goods or services, or whose behavior is monitored, are located; where they are spread across several, the choice is made and the reason recorded rather than defaulting to wherever a service was cheapest. The mandate given to the representative says that it may be addressed - in addition to the organization or instead of it - by supervisory authorities and by individuals, on all issues relating to the processing, for the purpose of ensuring compliance; and the organization gives it what it needs to answer: access to the record of processing activities, a route into the rights-request process, and a named internal contact who responds inside a stated time. The representative’s identity and contact details are published where the people who need them will look, and the appointment is reviewed when the processing, the markets served or the representative itself changes.", "crosswalks": { "gdpr": [ "Art.27(1)", "Art.27(3)", "Art.27(4)" ] } }, { "key": "processor-obligations", "name": "Obligations when acting as a processor", "description": "Where the organization processes personal data on behalf of somebody else, it runs that work as a processor rather than as an owner of the data. It engages no further processor - no subcontractor, no infrastructure provider handling the data, no offshore support team - without the customer’s prior written authorization, whether that authorization was given specifically for this one or generally for a class of them; and where it is general, the organization tells the customer in advance of any intended addition or replacement, in time and with enough detail for the customer to actually object, rather than announcing a change after it has happened. Any further processor it does engage is bound by contract to the same data protection obligations the organization itself is under, with sufficient guarantees that it will implement appropriate technical and organizational measures - and where that party fails, the organization remains fully liable to its customer for that failure rather than pointing at the subcontractor. The contract or other legal act governing the work is in writing, electronic form included, and is in place before the data arrives. Anyone acting under the organization’s authority who has access to the personal data - staff, contractors, administrators, and the further processors themselves - processes it only on the customer’s documented instructions, unless a law requires otherwise, in which case the organization tells the customer about that legal requirement before processing unless the law forbids it from saying so; instructions are recorded, and an instruction the organization believes to be unlawful is challenged rather than followed silently. On becoming aware of a personal data breach affecting the customer’s data, the organization notifies that customer without undue delay - it does not run its own risk assessment first and it does not wait for the investigation to conclude - and follows up with what it learns.", "crosswalks": { "gdpr": [ "Art.28(2)", "Art.28(4)", "Art.28(9)", "Art.29", "Art.33(2)" ] } }, { "key": "processor-record-of-processing", "name": "Processor’s record of processing categories", "description": "Where the organization processes personal data on behalf of other organizations, it keeps a second register, separate from the record of the processing it carries out for its own purposes: a record of the categories of processing it performs for each customer. Each entry carries the name and contact details of the organization itself and of the customer it is acting for, together with those of either party’s representative and of a data protection officer where one exists; the categories of processing performed for that customer; any transfer of the data to another country or an international organization, identifying the destination and, where the transfer rests on a compelling-legitimate-interests assessment, documenting the safeguards relied on; and a general description of the technical and organizational security measures protecting it. The register is kept in writing, electronic form included, is updated as customers and services change rather than assembled when somebody asks, and is held where it can be produced without a project to reconstruct it.", "crosswalks": { "gdpr": [ "Art.30(2)", "Art.30(3)" ] } }, { "key": "supervisory-authority-engagement", "name": "Supervisory authority cooperation & prior consultation", "description": "The organization knows which supervisory authority is competent for it, names the role that deals with that authority, and cooperates with it on request in the performance of its tasks - answering questions, producing documents, giving access, and meeting the deadline the authority sets rather than the one that suits the organization. That reaches its records of processing activities specifically: the register, and the processor register where it keeps one, is made available to the authority when asked, in a form the authority can read, which means the registers are kept in a state where producing them is an export rather than a project. Where an impact assessment concludes that the intended processing would result in a high risk to people in the absence of measures the organization takes to mitigate that risk, the organization consults the authority before the processing begins - it does not start and consult in parallel, and it does not treat a residual high risk as a matter for its own risk acceptance. What goes to the authority for that consultation is fixed rather than assembled ad hoc: the respective responsibilities of the organization, of any joint controllers and of the processors involved, in particular where the processing runs across a group; the purposes and the means of the intended processing; the measures and safeguards protecting the rights and freedoms of the people affected; the contact details of the data protection officer where one is designated; the impact assessment itself; and anything further the authority asks for. Correspondence with the authority is logged, its advice is recorded together with what was done about it, and the processing does not proceed until the consultation has run its course.", "crosswalks": { "gdpr": [ "Art.30(4)", "Art.31", "Art.36(1)", "Art.36(3)" ] } }, { "key": "dpo-designation", "name": "Data protection officer designation", "description": "Whether a data protection officer is required is a decision the organization takes explicitly and records, against the three cases that make one mandatory: it is a public authority or body, other than a court acting in its judicial capacity; its core activities consist of processing that by its nature, scope or purposes requires regular and systematic monitoring of people on a large scale; or its core activities consist of large-scale processing of special category data or of data about criminal convictions and offenses. The assessment is redone when the business changes, because \"core activities\" is a fact about what the organization does now. Where one is required - or where the organization appoints one voluntarily and then holds itself to the same rules - the person is chosen on professional qualities, in particular expert knowledge of data protection law and practice and the demonstrated ability to perform the tasks the role carries, and the basis of that judgment is recorded rather than left as a job title. The role may be filled by an employee or under a service contract, and a group may share one provided the officer is easily reachable from each establishment. The contact details are published where the people who need them will find them - individuals, staff, and anyone whose data the organization holds - and are communicated to the competent supervisory authority, which is a separate act from publishing them and is evidenced separately. Both are refreshed when the holder changes, so a published address does not outlive the person behind it.", "crosswalks": { "gdpr": [ "Art.37(1)", "Art.37(5)", "Art.37(7)" ] } }, { "key": "dpo-position", "name": "Position & independence of the data protection officer", "description": "The data protection officer is placed where the role can work rather than added to an org chart. They are involved properly and in good time in every issue that relates to the protection of personal data - which means they are in the room when a new processing activity, product, supplier, transfer or incident is being decided, not asked to review it afterwards, and the routes that bring those matters to them are established rather than depending on somebody remembering. They are given the resources the role needs: time protected from other duties, budget, staff where the scale warrants it, access to the personal data and to the processing operations themselves rather than to summaries of them, and the training and professional development that keeps their expert knowledge current. They receive no instructions about how to exercise the role - nobody directs the conclusion they reach or the advice they give - and they are neither dismissed nor penalized for performing it, which covers the informal penalties as well as the formal ones: exclusion from decisions, withdrawal of resources, a worse review, a blocked promotion. They report directly to the highest level of management, and that reporting line exists in fact, with a route to raise a matter at that level without passing it through anyone whose decision is in question. They are bound by secrecy or confidentiality in performing the role, so somebody can raise a concern with them without it being repeated. Where they hold other duties as well, the organization checks that those duties do not create a conflict of interests - a person who decides the purposes and means of processing cannot also be the one who independently assesses it - and the check is repeated when their responsibilities change.", "crosswalks": { "gdpr": [ "Art.38(1)", "Art.38(2)", "Art.38(3)", "Art.38(5)", "Art.38(6)" ] } }, { "key": "dpo-tasks", "name": "Tasks of the data protection officer", "description": "The data protection officer’s remit is written down and is at least this: to inform and advise the organization and the employees who carry out processing about the obligations they are under; to monitor compliance with those obligations and with the organization’s own data protection policies - which includes how responsibilities for personal data are assigned, how awareness is raised, how the staff involved in processing operations are trained, and the audits that check all of it; to give advice on impact assessments where it is asked for and to monitor how those assessments are performed; to cooperate with the supervisory authority; and to act as the contact point for that authority on processing issues, including any prior consultation, and to consult it where a matter warrants it. Monitoring is an activity with output rather than a standing description: it produces findings, they go to somebody who can act on them, and what happened to them is recorded. In carrying all of this out, the officer works to the risk - what gets attention first, how deeply, and how often is decided from the nature, scope, context and purposes of the processing and from what it could do to the people whose data it is, rather than from an even sweep across everything the organization does. The remit is reviewed as the organization changes, so a role defined for what it processed two years ago is not still pointed there.", "crosswalks": { "gdpr": [ "Art.39(1)", "Art.39(2)" ] } }, { "key": "international-data-transfers", "name": "International transfers of personal data", "description": "Every route by which personal data leaves the region - a hosting location, a support team, a subcontractor, a backup, a group company, a remote administrator with access from elsewhere - is identified and mapped before it is relied on, and each one is placed on a transfer mechanism that is written down. Onward transfers are inside the same discipline: where the recipient may pass the data on again, that further movement is covered too, and the whole chain is arranged so that the level of protection the law guarantees is not undermined by the last step in it. Where a formal adequacy decision covers the destination, the organization records which one and keeps it under review, because such decisions are amended and withdrawn. Where none does, the transfer proceeds only where the organization has provided appropriate safeguards and the people whose data it is retain enforceable rights and effective legal remedies. Which safeguard is being used is recorded per transfer, from those available without any supervisory authority authorization - a legally binding and enforceable instrument between public bodies, binding corporate rules, standard data protection clauses adopted by the Commission or adopted by a supervisory authority and approved by the Commission, or an approved code of conduct or certification mechanism coupled with binding and enforceable commitments by the recipient to apply the safeguards including as regards individuals’ rights - and the organization also knows which routes are NOT available without authorization: bespoke contractual clauses agreed with the recipient, and provisions inserted into administrative arrangements between public bodies, both of which require the competent supervisory authority to authorize them before the transfer proceeds. A clause set is not treated as a safeguard on signature alone: the organization assesses whether the law and practice of the destination actually let the clauses work, and applies supplementary measures where they do not. Only where neither adequacy nor a safeguard is available does the organization look to a derogation, and then narrowly and per transfer rather than as a standing basis - explicit consent given after the person has been informed of the risks that follow from the absence of adequacy and safeguards; necessity for a contract with the person or for pre-contractual steps at their request; necessity for a contract concluded in their interest with another party; important reasons of public interest; bringing or defending legal claims; vital interests where the person cannot consent; or a transfer from a public register, which may not involve the whole register or entire categories of the data in it and, where the register is open only to persons with a legitimate interest, may be made only at their request or to them as recipients. Where none of those applies and the transfer rests instead on the organization’s compelling legitimate interests, the stricter conditions are checked and met - the transfer is not repetitive, concerns only a limited number of people, is necessary for interests not overridden by theirs, and all the circumstances have been assessed and suitable safeguards provided on the strength of that assessment - the supervisory authority is informed of the transfer, the people affected are told about it and about the interests pursued in addition to the ordinary information they are owed, and the assessment and the safeguards are documented in the record of processing activities rather than in a memo nobody can find.", "crosswalks": { "gdpr": [ "Art.44", "Art.46(1)", "Art.46(2)", "Art.46(3)", "Art.49(1)", "Art.49(2)", "Art.49(6)" ], "pipeda": [ "4.1.3" ] } }, { "key": "binding-corporate-rules", "name": "Binding corporate rules", "description": "Where a group of companies moves personal data between its members across borders on the strength of binding corporate rules, those rules are a document with required content rather than a statement of intent, and the organization can show it against the list. They specify the structure and contact details of the group and of each member; the transfers or sets of transfer they cover, with the categories of personal data, the types and purposes of processing, the types of people affected and the countries involved; that they are legally binding both inside the group and externally; how the general data-protection principles are applied - purpose limitation, minimizing what is held, limited storage periods, data quality, protection by design and by default, the legal basis for processing, the handling of special category data, the measures securing the data, and what is required of any onward transfer to a body the rules do not bind; the rights of the people whose data it is and how to exercise them, including the right not to be subject to a solely automated decision, the right to complain to the competent supervisory authority and to go to court, and the route to redress and, where appropriate, compensation for a breach of the rules; the acceptance by the group member established in the region of liability for breaches by any member outside it; how the people affected are told about the rules, in addition to the ordinary information they are owed; the tasks of the data protection officer or of whoever else monitors compliance with the rules, including monitoring training and complaint handling; the complaint procedures; the mechanisms for verifying compliance, which include data protection audits and methods of ensuring corrective action, with results reported to the person who monitors the rules and to the board of the controlling undertaking and available to the supervisory authority on request; how changes to the rules are recorded, reported internally and reported to the authority; how any legal requirement in a third country that is likely to have a substantial adverse effect on the guarantees the rules provide is reported to the competent authority; and the data protection training given to personnel with permanent or regular access to personal data. The rules are submitted for approval before they are relied on, and they are maintained afterwards - reviewed as the group changes, with each change reported through the mechanism the rules themselves establish.", "crosswalks": { "gdpr": [ "Art.47(2)" ] } }, { "key": "management-system-roles", "name": "Management system roles, responsibilities & authorities", "description": "Top management assigns the responsibilities and authorities for every role the management system depends on, communicates them to the people who hold them, and satisfies itself that they are understood rather than merely issued - understanding being established by asking, not inferred from an absence of questions. The assignment is written against named roles rather than named individuals, so it survives a departure, and it carries authority alongside duty: what the role may decide alone, what it must escalate, and to whom. Five assignments are made explicitly, because they are the ones most often left in the gap between functions. Someone is responsible for the management system conforming to the standard it is built against. Someone is responsible for the processes delivering the outputs they were designed to deliver. Someone is responsible for reporting on how the system is performing, and on the opportunities to improve it, to top management itself rather than to a layer beneath it. Someone is responsible for promoting focus on the customer across the organization. And someone is responsible for the integrity of the system being maintained when changes to it are planned and implemented, so a reorganization does not quietly dismantle a control nobody was watching. The assignments are reviewed when the organization changes, and the record is kept current rather than reconstructed at audit.", "crosswalks": { "iso-9001": [ "5.3" ], "iso-42001": [ "5.3" ] } }, { "key": "infrastructure-provision", "name": "Infrastructure for operating processes", "description": "The infrastructure the organization’s processes need in order to run, and to produce products and services that conform, is determined, provided, and then maintained rather than provided once and left to decay. What counts as infrastructure is stated rather than assumed: the buildings the work happens in and the utilities that serve them; equipment, including both the hardware and the software it runs; transportation, where moving people, materials or outputs is part of delivering the service; and the information and communication technology the processes depend on. Each is determined from what the processes actually require, so a shortfall reads as a shortfall against a named process rather than as a general complaint about the estate. Maintenance is planned rather than reactive - what is serviced, on what interval, by whom, and what evidence is kept - and provision is revisited when the volume, the mix or the location of the work changes, so infrastructure sized for what the organization used to do is not still carrying what it does now.", "crosswalks": { "iso-9001": [ "7.1.3" ] } }, { "key": "process-environment", "name": "Environment for the operation of processes", "description": "The environment the organization’s processes are operated in is determined, provided and maintained as a condition of the output conforming, not as a matter of comfort. It is treated as a combination of human and physical factors, and the organization says which of them matter to which process. Social factors - whether the work is non-discriminatory, calm and non-confrontational - psychological factors - whether it is stress-reducing, protects against burnout, and is emotionally supportive - and physical factors - temperature, heat, humidity, light, airflow, hygiene, noise - are each considered, and the ones a given process is genuinely sensitive to are specified with the range or condition that has to hold. What is specified is then provided and monitored rather than aspired to, and the specification is revisited when the process, the output or the workforce changes. Which factors are relevant differs sharply with what is being delivered, so the determination is made per process rather than issued once for the whole organization.", "crosswalks": { "iso-9001": [ "7.1.4" ] } }, { "key": "monitoring-measuring-resources", "name": "Monitoring & measuring resources", "description": "Where the organization monitors or measures something in order to verify that products and services conform to requirements, the resources it uses to do so are determined and provided rather than borrowed, and they are chosen to be suitable for the specific type of monitoring or measurement being carried out - so an instrument with the wrong range, resolution or tolerance is caught at selection rather than in a dispute. Once provided, they are maintained so that they stay fit for their purpose: serviced, checked, protected from damage and from deterioration in use and in storage, and withdrawn when they are no longer fit. What the organization holds is recorded, with what each item is used for and who is responsible for it. Evidence that the resources are fit for their purpose is retained as documented information rather than asserted at audit, and it is retained for as long as the measurements they produced are relied on, not only for the current year.", "crosswalks": { "iso-9001": [ "7.1.5.1" ] } }, { "key": "measurement-traceability", "name": "Measurement traceability & calibration", "description": "Where measurement traceability is a requirement - because a regulation, a contract, a customer or the organization’s own judgment makes it one - measuring equipment is tied back to something outside itself. It is calibrated or verified, or both, at defined intervals and before use, against measurement standards traceable to international or national measurement standards; where no such standard exists, the basis actually used for the calibration or verification is retained as documented information, so an in-house reference is a stated basis rather than a gap. Every item carries its status, identified so that anyone picking it up can tell whether its calibration is current. It is safeguarded from adjustment, damage or deterioration that would invalidate the calibration status and the measurement results that follow from it. And when equipment is later found unfit for its purpose, the organization does not stop at fixing the equipment: it determines whether the validity of previous measurement results has been adversely affected, and takes appropriate action on the product or service those results released, up to and including recall.", "crosswalks": { "iso-9001": [ "7.1.5.2" ] } }, { "key": "organizational-knowledge", "name": "Organizational knowledge", "description": "The knowledge the organization needs in order to operate its processes and achieve conformity of products and services is determined, held, and made available to the people who need it, instead of living in whoever happens to still work here. What is determined covers both sources. Internal knowledge: what was learned from failures and from successful projects, the undocumented expertise of experienced people, intellectual property, and the improvements captured from changes to processes, products and services. External knowledge: standards, academic and professional bodies, conferences, and what customers and external providers know. It is maintained rather than accumulated - reviewed for whether it is still correct, and held in a form the roles that need it can actually reach at the moment they need it. When needs and trends change, the organization considers its current knowledge against the change and determines how it will acquire or access whatever additional knowledge is required, including what it will do about a body of knowledge that is about to leave with a person.", "crosswalks": { "iso-9001": [ "7.1.6" ] } }, { "key": "design-development-process", "name": "Design & development process", "description": "Where the requirements for what the organization will provide are not already fixed by the customer or by an external specification, the organization establishes, implements and maintains a design and development process, and its extent is appropriate to what is being designed and to what would follow if the design were wrong. The process is a defined route from a stated need to a specification that can be delivered against - named stages, entry and exit conditions, and an owner - rather than an informal habit that produces a drawing. It is written down, applied to every product and service that goes through design, and maintained as the organization’s offering changes. Where the organization concludes that design and development does not apply to it, because it produces to a customer’s specification or resells what others design, that conclusion is recorded with the reason it holds, so an absent process is a stated decision instead of an unexplained gap.", "crosswalks": { "iso-9001": [ "8.3.1" ] } }, { "key": "design-development-planning", "name": "Design & development planning", "description": "The stages of a design and the controls applied at each of them are planned before the design work starts, and the plan is proportionate to what is being designed. In deciding it, the organization considers the nature, duration and complexity of the design activity; the process stages required, including the design reviews that will be held; the verification and validation activities that will be performed and where in the sequence each of them falls; the responsibilities and authorities involved; the internal and external resources the design will need; the interfaces between the people and the functions involved, and how those interfaces will be controlled so that a handoff is not a hole; whether customers or users need to be involved and how; what will be required for the subsequent provision of the product or service, so the design is planned against how it will be made and delivered; the level of control the customer and other relevant interested parties expect over the design; and the documented information needed to confirm afterwards that the design requirements were met. The plan is documented, and it is revised when the design changes shape rather than left as the version written at kickoff.", "crosswalks": { "iso-9001": [ "8.3.2" ] } }, { "key": "design-development-inputs", "name": "Design & development inputs", "description": "What a design has to satisfy is determined and recorded before the design is worked up, and it is determined at the level of specificity the type of product or service requires rather than as a statement of intent. The inputs cover the functional and performance requirements the output must meet; information derived from previous design activity of a similar kind, so a known failure is not designed in again; the statutory and regulatory requirements that apply; standards or codes of practice the organization has committed to implement; and the potential consequences of failure given the nature of the product or service. Inputs are checked for being adequate for the purpose, complete and unambiguous, and any conflict between them is resolved before the design proceeds rather than settled implicitly by whoever builds it. The inputs are retained as documented information, so what the design was supposed to do can be established later without relying on memory.", "crosswalks": { "iso-9001": [ "8.3.3" ] } }, { "key": "design-development-controls", "name": "Design & development controls", "description": "The design is controlled while it is being produced, so that a defect is found while it is still cheap. Four things are done and kept distinct. The results the design is to achieve are defined, so there is a stated target to judge against. Reviews are conducted at the planned points to evaluate whether the design results meet the requirements. Verification is carried out to establish that the design outputs meet the design inputs - the right answer to the question that was asked. And validation is carried out to establish that the resulting product or service meets the requirements for the specified application or intended use, where that is known - the right question. Where any of these finds a problem, action is taken on it and tracked to closure rather than noted. The reviews, the verification and the validation have distinct purposes and may be run together on a single occasion, provided the record shows which of the three each finding came from. Documented information on all of these activities, and on the actions they produced, is retained.", "crosswalks": { "iso-9001": [ "8.3.4" ] } }, { "key": "design-development-outputs", "name": "Design & development outputs", "description": "What a design produces is checked against four separate tests before it is handed on, and the check is recorded rather than assumed from the design having finished. The outputs meet the input requirements that were determined for the design, so the thing built answers the question that was asked. They are adequate for the processes that follow - purchasing, production, service delivery and the maintenance of the product after it is delivered - which means each of those functions can work from what it is given without inventing the part that is missing. They include or reference the monitoring and measuring requirements that apply, and the criteria by which an output is accepted or rejected, so acceptance is a stated threshold instead of a judgment made at the point of release. And they specify the characteristics of the product or service that are essential for its intended purpose and for its safe and proper provision, including the ones that carry a safety or regulatory consequence if they drift. Outputs are issued in a form that lets verification and validation actually be performed against them - a drawing, specification, formulation, parts list, test method, work instruction, or service definition that somebody other than the designer can test - rather than as a description that can only be judged by the person who wrote it. They are approved by a role entitled to approve them before they are released to the next stage, and documented information on the outputs is retained, so what the design actually specified can be established later against what was made.", "crosswalks": { "iso-9001": [ "8.3.5" ] } }, { "key": "design-development-changes", "name": "Design & development changes", "description": "A change made to a design - during the design work, or afterwards once the product or service is already being provided - is identified as a change, reviewed, and controlled to the extent necessary to ensure it does not adversely affect conformity to requirements. The review asks what else the change touches: the inputs it invalidates, the verification and validation that has to be repeated, the documentation and the downstream processes that have to move with it. The change is authorized by a role entitled to authorize it before it takes effect. Documented information is retained on the changes themselves, on the results of the review, on the authorization of the change, and on the actions taken to prevent an adverse effect - so a change is answerable afterwards rather than visible only as a difference between two versions.", "crosswalks": { "iso-9001": [ "8.3.6" ] } }, { "key": "production-service-control", "name": "Control of production & service provision", "description": "Production and the provision of services are carried out under conditions the organization has defined in advance and can show were in place, rather than under whatever conditions the day produced. Those conditions are stated: documented information defining the characteristics of what is to be produced, the service to be provided or the activity to be performed, and the results to be achieved; suitable monitoring and measuring resources available and actually used; monitoring and measurement carried out at the appropriate stages to verify that the criteria for control of processes and the criteria for acceptance of outputs have been met; suitable infrastructure and a suitable environment for the operation of the processes; competent people, including any qualification the work requires; validation, and periodic revalidation, of any process whose resulting output cannot be verified by later monitoring or measurement, because the only alternative is discovering the failure in use; and actions designed to prevent human error - a check, a forcing function, a second pair of eyes - rather than an instruction to be careful. Release, delivery and post-delivery activities are carried out under the same defined conditions.", "crosswalks": { "iso-9001": [ "8.5.1" ] } }, { "key": "output-identification-traceability", "name": "Identification & traceability of outputs", "description": "Outputs are identified by suitable means wherever identification is necessary to ensure the conformity of products and services, so that what something is - and which batch, order or version it belongs to - can be established without inference. The status of an output with respect to monitoring and measurement requirements is identified throughout production and service provision, so a unit that has not yet passed a check cannot be mistaken for one that has, at any point in the flow. And where traceability is a requirement, whether imposed by a regulator, a customer, a contract or the organization’s own risk judgment, the unique identification of the outputs is controlled and the documented information necessary to enable traceability is retained - so that from a delivered item the organization can work back to what went into it, and forward from a defect to everything else affected by it.", "crosswalks": { "iso-9001": [ "8.5.2" ] } }, { "key": "customer-property-care", "name": "Care of customer & external provider property", "description": "Property belonging to a customer or to an external provider is treated with care for the whole time it is under the organization’s control or in use by it, and the organization knows what it holds. Property here is not only physical: it includes materials, components, tools and equipment, premises made available for the work, intellectual property, and personal data. Each item is identified, verified on receipt against what was expected, and then protected and safeguarded against loss, against damage, and against use for anything other than what it was provided for. When any of it is lost, damaged, or otherwise found to be unsuitable for use, the organization reports that to its owner rather than absorbing it quietly, and retains documented information on what happened and on what was reported. Where the property is personal data, the handling obligations the organization is already under apply to it in addition to this duty rather than instead of it.", "crosswalks": { "iso-9001": [ "8.5.3" ] } }, { "key": "output-preservation", "name": "Preservation of outputs", "description": "Outputs are preserved during production and service provision to the extent necessary for them still to conform to requirements when they reach the customer, so that something made correctly is not delivered spoiled. Preservation is treated as covering the whole handling chain rather than storage alone: identification, handling, contamination control, packaging, storage, transmission or transportation, and protection. What each output actually needs is determined from what would degrade it - time, temperature, humidity, light, static, vibration or contamination, and in the case of information, corruption and unauthorized alteration - and the conditions are then specified, provided and checked rather than assumed from the warehouse being indoors. Preservation applies to the constituent parts of a product as well as to the finished output, so a component held badly is caught before it is built in.", "crosswalks": { "iso-9001": [ "8.5.4" ] } }, { "key": "production-change-control", "name": "Control of changes to production & service provision", "description": "A change to how something is produced, or to how a service is provided, is reviewed and controlled to the extent necessary to keep what is delivered conforming to its requirements - a new machine, a new material, a new supplier of a component, a new step, a new location, a new shift pattern, or a change to the people who do the work. The review establishes what the change would do to the output and to the process controls that protect it, and whether any verification or validation has to be repeated before the change takes effect. Documented information is retained describing the results of the review, the person or persons who authorized the change, and any necessary actions arising from the review - so the change has an owner and a rationale on the record rather than an effective date alone.", "crosswalks": { "iso-9001": [ "8.5.6" ] } }, { "key": "product-service-release", "name": "Release of products & services", "description": "Nothing is released to the customer until the organization has verified that the requirements for the product or service have been met. Release is a decision taken against planned arrangements, at the stages those arrangements set, and it does not proceed until those arrangements have been satisfactorily completed - unless it is otherwise approved by a relevant authority and, where applicable, by the customer, which is a documented exception rather than a routine. The organization retains documented information on the release: evidence of conformity with the acceptance criteria the output was judged against, and traceability to the person or persons who authorized the release, so a released item can be tied back to the individual who signed for it.", "crosswalks": { "iso-9001": [ "8.6" ] } }, { "key": "quality-performance-monitoring", "name": "Monitoring & measurement of quality performance", "description": "What the organization needs to monitor and measure in order to know whether it is performing and whether its quality management system is effective is decided in advance and written down, together with three further decisions that are usually left implicit: the methods for monitoring, measurement, analysis and evaluation that will be used, chosen so that they produce valid results rather than convenient ones; when the monitoring and measuring is to be performed; and when the results are to be analyzed and evaluated, which is a separate date from when they are collected. What is chosen reaches the conformity of products and services and the effectiveness of the system, not activity counts that are easy to produce. Documented information is retained as evidence of the results, so a measurement can be re-examined rather than only reported, and the set of things being measured is revisited when what the organization does, or what it is judged on, changes.", "crosswalks": { "iso-9001": [ "9.1.1" ] } }, { "key": "quality-data-analysis", "name": "Analysis & evaluation of quality data", "description": "The data and information that monitoring and measurement produce are analyzed and evaluated rather than filed, and the results are used to answer a fixed set of questions: whether products and services conform to requirements; the degree of customer satisfaction; how the quality management system is performing and whether it is effective; whether what was planned has been implemented effectively; whether the actions taken to address risks and opportunities were effective; how external providers are performing; and whether the system itself needs to be improved. The analysis distinguishes a trend from a single reading and states the basis on which it does so, and the evaluation is written as a conclusion with a consequence - what this means, and what should follow - rather than as a chart with no reader. The results are carried into management review and into the improvement process as inputs of record, rather than as slides prepared for a meeting.", "crosswalks": { "iso-9001": [ "9.1.3" ] } }, { "key": "sensitive-authentication-data", "name": "Sensitive authentication data not retained", "description": "The data a card presents in order to prove the card itself is genuine - the full contents of the magnetic stripe or its equivalent held on the chip, the verification code printed on or encoded into the card, and the PIN or the encrypted PIN block - is not kept once the transaction has been authorized. That holds everywhere it could come to rest and not only in the payment database: application and debug logs, request and response traces, message queues, error dumps and crash reports, support tickets and attachments, screenshots, analytics events, backups, and the file a developer copied in order to reproduce a problem. Where any of it genuinely has to be held before authorization, it is held only for as long as authorization takes, is protected with strong cryptography while it is there, is readable by the smallest set of people and services that can complete the work, and is removed by the process itself rather than by somebody remembering. The verification code is not kept after authorization in any form, encrypted included, because encryption changes who can read a value and not whether the organization is still holding it. Copies are searched for rather than assumed absent: the systems and stores in scope are examined on a defined cadence and after any change to the payment flow, what is found is securely destroyed and the destruction recorded, and the route that produced it - a verbose log level, a captured request, a helpful export - is closed so the same copy does not reappear next month.", "crosswalks": { "pci-dss": [ "3.3" ] } }, { "key": "pan-display-masking", "name": "Card number display masking", "description": "The full card number is not the default thing a screen shows. Displays are masked so that what appears is the smallest fragment that lets somebody do the job in front of them, and seeing more than that is a separately authorized act: the roles with a documented business need for the whole number are listed, each holder is approved individually, and the need is reviewed rather than inherited. Everybody else sees the masked form, and sees it whether or not their access would technically let them read the underlying record, because the masking is applied by the system rather than left to the discretion of whoever built the screen. It applies everywhere the number can be read and not only in the main application: administrative and support tooling, reports and dashboards, exports and extracts, printed and emailed documents, receipts, and anything shown to a third party. Where the number is reached through a remote-access technology - a published desktop or application, a support session, a screen-sharing tool, a virtual workspace - technical controls prevent it from being copied, downloaded or relocated onto the local machine unless the person is explicitly authorized and a documented business need says why, so a session that legitimately displays the data does not quietly become a route to a copy of it. Where a masking rule is relaxed for a person, a role or a screen, the relaxation is recorded with the need behind it, an owner and an expiry, and is reviewed on a cadence rather than left standing.", "crosswalks": { "pci-dss": [ "3.4" ] } }, { "key": "public-web-application-protection", "name": "Public-facing web application protection", "description": "An application the organization publishes to the internet carries a protection that runs continuously in front of it rather than a check that happened once. An automated technical solution sits ahead of each public-facing web application, inspecting the traffic that reaches it and detecting and preventing the web-based attacks the organization has decided it must withstand - injection, tampering with parameters and sessions, abuse of an authenticated function, and whatever classes its own findings and the wider threat picture put in front of it. It is actively running rather than installed, is kept current as new attack patterns are published, produces audit records that are retained and read, and is configured either to block what it detects or to raise an alert a named role acts on immediately - a decision taken deliberately for each application rather than left wherever the product shipped it. Coverage is answerable from the estate rather than from memory: the internet-facing applications are inventoried, each is matched to the protection standing in front of it, and one with no protection is a finding with an owner and a date rather than an omission nobody owns. New threats and vulnerabilities affecting these applications are tracked as they emerge and the application and its protection are updated for them. Where the organization runs assessment alongside that mechanism, that assessment runs on a stated cadence and again after every significant change, is performed by people or tools competent to do it, and its findings are remediated and retested rather than reported.", "crosswalks": { "pci-dss": [ "6.4" ] } }, { "key": "poi-device-protection", "name": "Payment terminal protection", "description": "The devices a customer physically presents a card to are protected against being tampered with or swapped, because a terminal is the part of the payment path an attacker can reach with their hands. The organization keeps a current list of every such device in its care - make and model, location, serial or other unique identifier, and the person answerable for it - and updates the list when a device is added, moved, returned or retired. Devices are inspected against that list on a stated recurring cadence, and the inspection looks for what actually happens: a serial number that no longer matches, a housing or seal that has been opened, a cable, overlay, reader or attachment that was not there before, a device substituted while nobody was watching, and changes to the surroundings that would let somebody observe a PIN being entered. What each inspection found, when, and who performed it is recorded rather than confirmed verbally. The staff who work with the devices are trained for the part only they can do: to verify the identity and the authorization of anybody claiming to install, service, replace or inspect a device before letting them near one, to refuse an unexpected visit and check it against a known contact, to recognize behavior around a terminal that does not belong, and to know exactly who to tell and how quickly. Devices held in stock, in transit or awaiting repair are controlled on the same terms as devices in use, and a device suspected of tampering is taken out of service under a documented route rather than left running while somebody decides.", "crosswalks": { "pci-dss": [ "9.5" ] } }, { "key": "payment-page-script-integrity", "name": "Payment page script integrity", "description": "Every script that a customer’s browser loads and runs on a page where payment details are entered is known, justified and watched, because that page executes in an environment the organization does not control. Each script is inventoried with what it does, why it is needed and who authorized it, and one nobody can justify is removed rather than left because it has always been there - including the scripts that arrive indirectly, through a tag manager, an analytics package, a chat or support widget, or as a dependency of another script. The integrity of each is assured by a mechanism the organization can evidence, such as pinning it to a known hash, constraining what the page is permitted to load, serving it from somewhere the organization controls, or an equivalent chosen deliberately and written down. What the browser actually receives is then checked on a defined cadence - weekly, unless a documented targeted risk analysis supports a different one - covering both the scripts the page loads and the HTTP headers it returns, and compared against what was authorized. A change nobody approved raises an alert to a named role who investigates it as a possible compromise rather than as a release note, and the check itself is monitored, so a check that has silently stopped running is noticed rather than trusted.", "crosswalks": { "pci-dss": [ "11.6" ] } }, { "key": "service-provider-responsibility-acknowledgement", "name": "Service provider responsibility acknowledgement", "description": "Where the organization holds, processes or transmits payment or account data on behalf of its customers, it says so to them in writing rather than leaving the division of duty to be inferred from a contract about something else. The acknowledgement states that the organization is responsible for the security of the data it holds on the customer’s behalf, and for anything within its service that could affect the security of the customer’s own environment; it is given before the service starts and given again when the service changes materially. Alongside it the organization maintains a written division of responsibility - which requirements it meets on the customer’s behalf, which remain the customer’s, and which are shared and in what proportion - specific enough that a customer can see what it still has to do rather than being told the service is compliant and left to guess. Evidence of the organization’s own standing is kept current and provided on request: the assessment or attestation it holds, its date, what it covers and what falls outside it. Requests from customers for any of this go to a named owner and are answered within a stated time, and the organization tells affected customers when its own standing changes rather than waiting to be asked at renewal.", "crosswalks": { "pci-dss": [ "12.9" ] } }, { "key": "over-rated-content-age-restriction", "name": "Age restriction on creator content above the app’s rating", "description": "Where an app presents material authored by a community of non-developer creators rather than by the developer itself, two things are built rather than assumed. First, a user can tell which of that content exceeds the app’s own age rating: the rating of each item is carried through to the place where a user chooses it - the feed, the browse or search result, the channel or profile page, the thumbnail - so a parent or an older user sees the difference before opening it rather than afterwards. Second, an age restriction mechanism acts on an age signal, verified or declared, to keep underage users out of the creator content that exceeds the rating, so the labeling is enforced rather than merely displayed. The mechanism covers every route into that content, including a direct link, a share, an embed and a recommendation, because a gate on the browse surface alone is not a restriction. What the mechanism does when there is no age signal at all is decided in advance and written down rather than defaulting to access, and a creator item whose rating has never been established is treated under that same written rule rather than as unrated-therefore-open.", "crosswalks": { "apple-kids": [ "1.2.1(a)" ] } }, { "key": "over-rated-software-age-restriction", "name": "Age restriction on non-embedded software above the app’s rating", "description": "Where an app offers software that is not embedded in its own binary - HTML5 and JavaScript mini apps and mini games, streaming games, chatbots, plug-ins, and retro console or PC emulators offering downloadable titles - two things are built rather than assumed. First, a user can tell which of that software exceeds the app’s own age rating: each title carries its rating through to the place where a user launches or installs it, including the in-app store or catalog, the search result and the recommendation, so the difference is visible before the software runs rather than after. Second, an age restriction mechanism acts on an age signal, verified or declared, to keep underage users out of the software that exceeds the rating, and it acts at launch rather than only at listing, so a deep link, a shared invite or a resumed session does not bypass it. The rating relied on for each title is recorded with where it came from - the developer’s own classification, the third-party publisher’s, or a rating body’s - so a title running without an established rating is a finding with an owner rather than an omission, and it is handled under the written rule for what the mechanism does when a rating or an age signal is absent instead of defaulting to access.", "crosswalks": { "apple-kids": [ "4.7.5" ] } }, { "key": "ad-creative-age-review", "name": "Human review of ad creative for age appropriateness", "description": "Every advertisement that can be displayed to a child is reviewed by a person for whether it suits that audience before it is allowed to run, and the review is recorded against the creative it approved. This is a duty on the developer rather than a question about the ad vendor, and it reaches creative no third-party network ever touched: the app’s own house ads, cross-promotions for the developer’s other titles, sponsor placements sold directly, and anything served through a partner or a mediation layer. Where creative does arrive from an ad service, the service’s own human review is evidenced from its published practices rather than assumed from its reputation, and the developer still keeps its own record of what it accepted. Approval is per creative rather than per campaign, an approved creative is reviewed again when it changes, and there is a stated route to pull one that is already running.", "crosswalks": { "apple-kids": [ "1.3/advertising-human-review" ] } }, { "key": "child-account-authentication-alternative", "name": "Alternative sign-in for users under 13", "description": "Where an app authenticates an account using facial recognition, a user under 13 can sign in another way. Two things follow and both are built: the app holds an age signal at account level, so it knows which accounts the alternative is owed to, and a working fallback credential exists and is tested rather than assumed - an account that can only be opened by a face is unusable by exactly the users this exists for. The alternative is offered rather than hidden behind a support request: it appears on the sign-in path itself, and choosing it does not cost the user functionality the face route would have given them. Where the app cannot establish an age, it treats the account as one that needs the alternative rather than one that does not. This is a control over the route into an account, and it is separate from any consent or data-handling duty the biometric feature itself attracts.", "crosswalks": { "apple-kids": [ "2.5.13/under-13-alternate-authentication" ] } }, { "key": "research-participant-consent", "name": "Consent from human subject research participants", "description": "An app that conducts health-related human subject research obtains consent from each participant before enrolling them, and where the participant is a minor that consent comes from a parent or guardian rather than from the minor. The consent covers a fixed set of things and is evidenced as having covered them: the nature, purpose and duration of the research; the procedures involved and the risks and benefits to the participant; how confidentiality and the data will be handled, including any sharing with third parties; a point of contact for the participant’s questions; and how a participant withdraws. Each is recorded as it was actually presented rather than as it was intended, so a change to the protocol, or to who receives the data, is a change to what was consented to and triggers consent again. The withdrawal route is operable rather than described: a request reaches a named owner, further collection stops, and what happens to data already collected is stated to the participant in advance instead of decided afterwards. This is consent to take part in research, and it is not the same act as verifiable parental consent to collect a child’s personal information - an app doing both performs both.", "crosswalks": { "apple-kids": [ "5.1.3(iii)/minor-parental-consent" ] } }, { "key": "child-app-permission-implementation", "name": "Restricted platform permissions in children’s apps", "description": "Where a store requires a device capability to be requested through a specific, narrower platform API rather than through the broad permission, the app calls that API. Google Play requires an app in its Families program to request Bluetooth through the Companion Device Manager, which binds the grant to one device the user chooses instead of giving the app open scanning access to everything nearby; the app is built that way rather than granted the broad permission and trusted to behave. The one stated way out is an app targeting only operating-system versions that cannot support the narrower API, and that is a claim the build has to bear out: the declared minimum supported version is recorded beside the exemption and re-checked whenever it is raised, because raising it takes the exemption away. Evidence is read off the app rather than off the policy - the permissions the manifest declares, the pairing flow a user actually meets, and a review of both at each release, so a permission introduced by a dependency is caught before it ships.", "crosswalks": { "google-play-families": [ "families/requirements/bluetooth-cdm" ] } }, { "key": "financial-reporting-scoping", "name": "Scope of the financial reporting assessment", "description": "Before anything is tested, the organization states what the financial statements have to achieve and which parts of them the assessment covers, because a control program with no stated objective tests whatever is convenient to test. Materiality is set and the basis it was derived from is written down rather than carried over from last year. The accounts and disclosures that matter are identified, each with the reason it qualified - its size and composition, how susceptible it is to error or fraud, the volume and complexity of what flows through it, the accounting and reporting judgments it involves, its exposure to loss or to a contingent liability, whether related parties transact in it, and what has changed about it since the prior period. For each of those, the assertions genuinely at risk are named - that the balance exists and the transactions occurred, that nothing is missing, that amounts are valued or allocated correctly, that the rights and obligations are the organization’s own, and that it is presented and disclosed properly - rather than testing every assertion of every account at the same depth. The likely ways each could be misstated are recorded alongside them, which is what makes the risk work that follows specific rather than generic. The scope is revisited when the business, the accounting standards or the systems change, and what came into and out of scope is recorded with the reason, so the boundary is answerable rather than inherited.", "crosswalks": { "sox": [ "P6" ] } }, { "key": "financial-reporting-risk-assessment", "name": "Financial reporting risk assessment", "description": "Against the objective and scope already stated, the organization identifies what could cause the financial statements to be materially misstated, and does so across the whole reporting entity - the parent, its subsidiaries and divisions, the locations that roll up into the consolidation, and the third parties whose work ends up in the numbers, including outsourced processing and service providers. The sources are worked through rather than brainstormed: how the applicable accounting framework applies to the transactions this business actually enters into; how each of those is initiated, authorized, processed and recorded; the estimates and judgments management makes; and the internal and external changes that alter any of them. Each identified risk is analyzed for how likely it is and for what it would do if it happened, and every one leaves the assessment with an explicit decision on how it is being managed - a register with no response column records worry rather than management. The assessment is refreshed on a defined cadence and, separately, whenever something happens that changes it, so it is not a document produced once a year and filed. What was considered and set aside is recorded as well as what was accepted, so a later reviewer can see the boundary of the exercise instead of inferring it.", "crosswalks": { "sox": [ "P7" ] } }, { "key": "esg-risk-management", "name": "ESG risk identification & treatment", "description": "Environmental, social and governance risks are identified, rated and treated through the organization’s risk process rather than tracked in a separate document nobody acts on. What is looked for is stated so the exercise is repeatable: the environmental risks the operation and its supply chain create and are exposed to; the risks to and from the people the organization employs, sells to and operates among; and the governance risks that come from how it is directed, incentivized and held to account. Each risk gets a named owner, an assessment of how likely it is and what it would cost - in money, in harm to people, and in the organization’s standing - and a decided treatment with a date, and the treatments are followed up rather than merely recorded. The same criteria and the same register the organization uses for its other risks apply here, so an ESG risk is weighed against everything else competing for attention instead of considered beside it. The set is reviewed on a defined cadence and again when the operation, the supply chain, the regulatory position or the stakeholder picture changes, and what the review changed is recorded.", "crosswalks": { "esg-essentials": [ "G.6" ] } }, { "key": "work-authorization-verification", "name": "Employment eligibility verification", "description": "Every new hire’s identity and authorization to work is verified on the required form, inside the statutory window, and in a way that does not discriminate. The employee completes their own section at the time of hire; the employer examines the documentation the employee presents and completes the employer section within three business days of the hire, and where the engagement will last less than three business days, at the time of hire. Which acceptable documents to present is the employee’s choice: the employer does not specify which ones it wants, does not ask for more or different documents than the form requires, and does not refuse documents that on their face reasonably appear to be genuine and to relate to the person - demanding extra papers is itself the unlawful act rather than an inconvenience. Citizenship status and national origin play no part in whether, when or how the check is run, so the same process is applied to everyone hired. Completed forms are held so they can be produced on request within the notice an inspection carries, and kept apart from the general personnel file where that is practical. Where an authorization expires and re-verification is required, it is diarized against the date rather than noticed once it has passed, and the people who run onboarding are trained on all of this, because the discriminatory version of this control is usually performed by somebody being helpful.", "crosswalks": { "us-employment-federal": [ "us.hiring-onboarding.i9" ] } }, { "key": "wage-hour-records", "name": "Time and pay records", "description": "The organization creates and keeps an accurate record of the hours each non-exempt worker actually worked and the wages actually paid, because this is a duty to PRODUCE a record and not only to keep one - a period nobody wrote down cannot be reconstructed later. For each such worker the record carries who they are and the identifying details the regulations call for, the time and day of the week the workweek begins, hours worked each day and the total for each workweek, the basis on which the wages are paid, the regular hourly rate, straight-time and overtime earnings for the workweek, every addition to and deduction from wages, total wages for the pay period, and the date of payment with the period it covers. No particular form or timekeeping method is required - a clock, a timekeeper, or workers writing their own times all qualify - provided what results is complete and accurate, so the method is chosen deliberately, written down and checked rather than trusted. Payroll records are preserved for at least three years, and the records the wage computations were built from - time cards, work and time schedules, wage-rate tables, and records of additions to and deductions from wages - for at least two, held where they can be produced for inspection. A correction is made as a correction, with what changed, when and why still visible, rather than by overwriting the original.", "crosswalks": { "us-employment-federal": [ "us.wage-hour.recordkeeping" ] } }, { "key": "nursing-employee-break-and-space", "name": "Break time and space for nursing employees", "description": "A nursing employee can take the break time they need to express breast milk, as often as they need it, for one year after the child’s birth, and has somewhere to do it. The space is not a bathroom - a private one does not qualify - and it is shielded from view and free from intrusion by coworkers and the public. It has to be functional for the purpose rather than merely nominated: somewhere to sit, a surface, and availability when the employee needs it. A space that is not dedicated to this use is acceptable only where it is genuinely free at the moment it is needed, so a room that is usually occupied, or that has to be negotiated for each time, is not the space this requires. Break time is unpaid only where the employee is completely relieved of duty for it: time spent pumping while doing any work is worked time, and where the employer already provides paid breaks, an employee who uses one for this is paid for it the same way as anyone else. The arrangement is communicated to the employee and to the managers who schedule them, and requests go to a named owner, so access does not depend on an individual negotiating for it. Where an employer with fewer than 50 employees relies on the undue-hardship relief the statute allows, the hardship is assessed and recorded against the difficulty and expense in the circumstances of that business rather than asserted.", "crosswalks": { "us-employment-federal": [ "us.leave.pump-act" ] } }, { "key": "polygraph-testing-limits", "name": "Lie-detector testing limits", "description": "The organization does not require, request, suggest or cause an employee or a job applicant to take a lie detector test, and does not use, accept, refer to or ask about the results of one. Nobody is discharged, disciplined, denied employment or otherwise discriminated against for refusing a test, for filing a complaint, or for taking part in a proceeding about one. The prohibition lives in hiring practice as much as in investigations, so recruiters, hiring managers and anyone who runs an internal investigation are told it exists - the request is most often made informally, by somebody who did not know they could not make it. Where the organization believes one of the narrow statutory exemptions applies - certain applicants at armored car, alarm and guard firms, certain applicants at manufacturers, distributors and dispensers of controlled substances, or an employee reasonably suspected of involvement in a workplace incident that caused a specific economic loss or injury - the decision is taken in advance by a named owner, the basis for it is written down, and the conditions attached to the exemption are met rather than assumed: an examiner who is licensed and bonded or carries professional liability coverage, the pre-test, test and post-test conduct the rules require, and the strict limits on who may be told the result. The records the statute requires are kept, and the notice it requires is posted where employees will see it.", "crosswalks": { "us-employment-federal": [ "us.privacy.polygraph" ] } }, { "key": "employee-monitoring-lawful-basis", "name": "Lawful basis for monitoring employee communications", "description": "Before any monitoring that could intercept an employee’s communications is switched on, the organization decides and records what makes it lawful, because federal law prohibits intercepting a wire, oral or electronic communication unless an exception applies, and a policy that merely announces monitoring is not one of them. Each monitoring practice is written down on its own - what is captured, from which systems and endpoints, whether content or only metadata, who can see it, how long it is held and what it may be used for - and each carries the basis it relies on, most commonly the prior consent of a party to the communication, or the route that turns on equipment furnished by the service provider and used in the ordinary course of business. Consent, where it is relied on, is obtained and evidenced rather than inferred from a handbook nobody signed, and it is obtained before the monitoring starts. The monitoring then stops where its basis stops: it continues only so far as the exception reaches, communications that fall outside it are not swept in by default, and a practice that has outgrown its basis is re-decided rather than quietly extended. Where employees are told how they are monitored, that notice matches what is actually done. State and local law can be stricter than the federal floor, so the basis is checked against the jurisdictions the workforce actually sits in, and a monitoring practice with no recorded basis is switched off until it has one.", "crosswalks": { "us-employment-federal": [ "us.privacy.electronic-monitoring" ] } }, { "key": "fedramp-security-inbox", "name": "FedRAMP security inbox", "description": "A dedicated email address exists for correspondence from FedRAMP, and it is the address FedRAMP has on record. It is monitored rather than merely created: mail reaches a person who can act on it, without FedRAMP having to take any extra step to get through. Whenever the address changes, FedRAMP is told at once, because an inbox FedRAMP cannot reach is the same as no inbox. Mail arriving from @fedramp.gov or @gsa.gov is treated as genuinely from FedRAMP unless it is positively established to have come from somebody else, so a filter, a quarantine rule or an over-eager spam policy does not silently discard a message the organization is obliged to act on. Messages are triaged by the urgency FedRAMP assigns them, and the duties differ by designator. Emergency messages are routed to a senior security official for their awareness, and the required actions in an Emergency or Emergency Test message are completed inside the timeframe the message sets rather than the organization’s ordinary service level. FedRAMP recommends two further practices this control adopts: acknowledging receipt promptly and automatically, and completing what an Important message asks inside its stated timeframe, which can itself vary by certification class. Because the duty is continuity of contact rather than possession of a mailbox, the arrangement survives holidays, staff changes and mail-platform migrations, and somebody owns it by name.", "crosswalks": { "fedramp-rules-2026": [ "AFC-CSO-INB", "AFC-CSO-NOC", "AFC-CSO-TFG", "AFC-CSO-RCV", "AFC-CSO-CRA", "AFC-CSO-EMR", "AFC-CSO-IMA", "AFC-CSO-ACK" ] } }, { "key": "fedramp-marketplace-listing", "name": "FedRAMP Marketplace listing", "description": "The offering is listed in the FedRAMP Marketplace, and the listing is obtained the way FedRAMP requires it to be: through the Marketplace Provider Listing Request Form, submitted by the provider, addressing the FedRAMP rules the listing requirements name. That applies to a new listing and to an update of an existing one, so a listing is maintained rather than filed once. A listing in the Initial Implementation Phase carries three further duties, and they are easy to let lapse. The offering is shown to be intended for one of the use cases FedRAMP recognizes, which are direct use by an agency inside a federal information system that will receive an Authorization to Operate, or indirect use as a third-party resource inside another offering agencies use directly. Continuous progress toward certification is demonstrated against goals and milestones the provider documents, published in the trust center or on the website where agencies can see them, and refreshed at least quarterly, so progress is evidenced in public rather than asserted in private. And an assessment for Class B, C or D is scheduled within two years of that initial listing, with the booking made rather than intended. A named owner holds the listing, because the Marketplace entry is what an agency finds first and a stale one misrepresents the service.", "crosswalks": { "fedramp-rules-2026": [ "MKT-CSO-MLR", "MKT-CSO-PML", "MKT-IIP-AGU", "MKT-IIP-DCP", "MKT-IIP-DLA" ] } }, { "key": "fedramp-certification-application", "name": "FedRAMP certification application", "description": "One target FedRAMP Certification Profile is chosen and every practice that follows from it is applied, and one program certification type is pursued for an offering rather than both: a service does not run a Rev5 Program Certification and a 20x Program Certification at the same time. Applying is a sequence, and the order is part of the requirement. The Marketplace listing comes first and meets the conditions attached to it, the Certification Application Form is then completed in full, and the provider applies on its own behalf - no third party, assessors included, may apply for it. The initial package shows the service’s status as verified and validated within the previous seven days, and where the class requires it, an independent assessment completed by a FedRAMP Recognized service within the previous three months. The package itself is complete against everything the rule enumerates, every machine-readable item a rule names is supplied as JSON valid against the FedRAMP schema for it, and the provider stays responsible and accountable for the accuracy and completeness of all of it, including for material a third party produced. A Rev5 Agency Certification additionally runs to the sponsoring agency’s Authorization to Operate process and holds the signed ATO letter. Changing class is a new application in either direction, up or down, and an upgrade additionally requires every applicable requirement to be met in advance; FedRAMP recommends at least 120 days’ notice to all necessary parties before a certification is downgraded or cancelled, which this control adopts, so agencies relying on it are not surprised. The certification type sets the rest. On Rev5 that means the NIST SP 800-53 Rev. 5 controls FedRAMP names for the class, every organization-defined parameter assigned the way FedRAMP Rev5 Controls Guidance says and each assignment recorded, and each applicable control implemented and documented that guidance’s way; a service holding Rev5 Ready status converts to a certification by whichever falls later, its annual assessment expiring or 17 November 2026. On 20x the duties tighten with the class rather than applying flat. Automated verification and validation of Key Security Indicators is optional at Class A, recommended at Class B with at least one automated method each, and required at Class C and D with at least two and at least four methods each. Historical metrics from persistent validation are optional at Class A, recommended at Class B, and required to cover at least the past six months at Class C and at least the past 18 months at Class D. Automating verification of the Security Decision Record against the rules is recommended rather than required at every class, and applying all Key Security Indicators across everything inside the FedRAMP Minimum Assessment Scope is likewise a recommendation this control adopts. Class A runs on an approved alternative security framework instead: a certification or equivalent process is completed under one FedRAMP approves, within the past 12 months and including its independent assessment where one applies, the materials FedRAMP names are handed to all necessary parties, and the mandatory Class A rule set is addressed in full, with the separately recommended Class A additions covered where they apply.", "crosswalks": { "fedramp-rules-2026": [ "FRC-CSO-FCP", "FRC-CSO-PKG", "FRC-CSO-JSN", "FRC-CSO-MRA", "FRC-CSO-POP", "FRC-CLA-ASF", "FRC-CLA-EAM", "FRC-CLA-MFR", "FRC-CLA-RFR", "FRC-APP-MLF", "FRC-APP-AFC", "FRC-APP-FCP", "FRC-APP-FIA", "FRC-APP-NTP", "FRC-APS-ATO", "FRC-CCL-UCC", "FRC-CCL-DCC", "FRC-CCL-DNP", "FRC-CSX-VVK", "FRC-CSX-MOT", "FRC-CSX-VVR", "FRC-CSX-MAS", "FRC-CSF-BSL", "FRC-CSF-ACP", "FRC-CSF-FFG", "FRC-CSF-RDY" ] } }, { "key": "fedramp-certification-package-overview", "name": "FedRAMP certification package overview", "description": "The certification package opens with an overview of the cloud service offering, supplied in both human-readable and machine-readable form and carrying everything the overview rules call for, so a reader and a parser see the same thing. It carries the basic metadata FedRAMP requires: the name, title and contact details of the official responsible and accountable for the package, its version, and the date, time and source of the last update. At Class B and above the assessor’s overall summary of the independent assessment sits in the overview rather than only deep in the assessment material, so the headline judgement is where somebody looking at the package first will find it; at Class A including it is optional. The package is then maintained on a cadence rather than assembled once for the application, and the cadence tightens with the class. On Rev5 it is brought current and complete at least once a year at Class B and C, and at least every six months at Class D. On 20x it is maintained at least every three months at Class A as a recommendation, then at least monthly at Class B, at least every two weeks at Class C and at least weekly at Class D. A named owner holds that cadence, because the package is what an agency reads to make an authorization decision and one that has quietly gone stale still reads as current.", "crosswalks": { "fedramp-rules-2026": [ "CPO-CSO-OVR", "CPO-CSO-MTD", "CPO-CSO-OSA", "CPO-CSX-CPM", "CPO-CSF-CPM" ] } }, { "key": "fedramp-certification-data-publication", "name": "FedRAMP certification data and trust center", "description": "Current information about the service is published in both human-readable and machine-readable form, covering everything applicable that FedRAMP asks for, together with a detailed list of the in-scope services and their security categories named the way the organization’s own public marketing names them, so an agency can match what it is buying to what is certified. Once a FedRAMP ID is assigned it appears in every report, notification and communication. FedRAMP Certification Reports go into the certification data without inappropriate modifications and within two weeks of arriving, relevant policies and procedures are included with a human-readable and a machine-readable reference explaining what FedRAMP requires of each, and where the class requires it, materials are supplied per service rather than only for the offering as a whole. A web service showing current and historical availability of the core services over at least the past 30 days, including availability incidents, is required from Class B upward and recommended at Class A, and it stays reachable even when the offering itself is not, which is the point of it. What is published is judged twice: agencies must get enough to make an authorization decision, and detail that would likely help an attacker should be left out rather than abstracted away into uselessness. Where the same fact exists in both formats, automation keeps the two consistent rather than a person remembering to update both. Snapshots aligned to each Ongoing Certification Report stay available to necessary parties for as long as the certification lasts, so a decision taken last year can still be traced to what was published at the time. The data is stored and shared through a FedRAMP-compatible trust center, and the trust center carries duties of its own: uninterrupted sharing with all necessary parties, documented programmatic access to everything including the human-readable material, an inventory and history of which agency users and systems hold access, handed to FedRAMP on request, and access logging with summaries stored at least six months, a party’s own record being made available on request. It should also allow viewing and downloading in both forms and let necessary parties provision and manage access for their own users and services. Agencies should be given access to the Certification Package when they ask; where a request is denied, FedRAMP is told within five business days. On Rev5, moving to a trust center is itself a notification event: all necessary parties are told, and the existing USDA Connect Community Portal secure folders are left carrying instructions explaining how to use the trust center to obtain the data from now on.", "crosswalks": { "fedramp-rules-2026": [ "CDS-CSO-PUB", "CDS-CSO-SVC", "CDS-CSO-FID", "CDS-CSO-FRC", "CDS-CSO-AVR", "CDS-CSO-UTC", "CDS-CSO-CBF", "CDS-CSO-RIS", "CDS-CSO-IRP", "CDS-CSO-HAD", "CDS-CSO-PSM", "CDS-TRC-USH", "CDS-TRC-PAC", "CDS-TRC-AAI", "CDS-TRC-ACL", "CDS-TRC-HMR", "CDS-TRC-SSM", "CDS-UTC-AAD", "CDS-UTC-AGA", "CDS-CSF-TCM" ] } }, { "key": "fedramp-ongoing-certification-reporting", "name": "Ongoing FedRAMP certification reporting", "description": "An Ongoing Certification Report goes to all necessary parties every three months, in a consistent human-readable format, covering everything that has happened since the last one, so the record is continuous rather than a series of snapshots with gaps between them. FedRAMP recommends settling that cycle into a steady rhythm spread away from the beginning, middle and end of each quarter, and this control adopts it. The target date of the next report is published alongside the rest of the public certification data so readers can plan around it. Sensitive detail is kept out where disclosing it would likely harm the service, which is a judgement made each time rather than a template setting. Each report carries an asynchronous route for necessary parties to ask questions or give feedback, and the answers are not left private: an anonymized, desensitized summary of the feedback and the responses is published, either as an addendum or in the following report. Alongside the reports, a synchronous Quarterly Review is hosted and open to all necessary parties, covering the parts of the recent reports most likely to matter to them, with whatever additional content is judged useful to agencies, and with the requirements varying by certification class. Necessary parties get either a registration link or a calendar file, and the date of the next review is published with the rest of the certification data. Three further FedRAMP recommendations are adopted here: scheduling each review at least three business days after a report goes out and within ten business days of it, so attendees have read the report and have not forgotten it; recording or transcribing reviews and supplying them to all necessary parties; and keeping third parties out of reviews intended for agencies unless they have specific relevance, the independent assessor counting as relevant by default. The same disclosure judgement applies in the room as on the page.", "crosswalks": { "fedramp-rules-2026": [ "CCM-OCR-AVL", "CCM-OCR-NRD", "CCM-OCR-FBM", "CCM-OCR-AFS", "CCM-OCR-LSI", "CCM-OCR-SOR", "CCM-QTR-MTG", "CCM-QTR-REG", "CCM-QTR-NRD", "CCM-QTR-NID", "CCM-QTR-SAR", "CCM-QTR-ACT", "CCM-QTR-RTR", "CCM-QTR-RTP" ] } }, { "key": "fedramp-independent-assessment", "name": "FedRAMP independent assessment", "description": "Every applicable FedRAMP rule is independently verified and validated by a FedRAMP Recognized service, on a persistent basis rather than once at application, with what that covers varying by certification class. The two halves are distinct and both are owed: assessors get evidence that the documented measures are actually implemented, which is what verification produces, and evidence that they are actually effective, which is what validation produces. FedRAMP also recommends supplying the technical explanations, demonstrations and other supporting material an assessor needs to understand how the organization’s capabilities address the rules, as far as is necessary for the assessor to complete verification and validation, and this control adopts it, so a finding turns on the substance rather than on what the assessor could work out unaided. Where representative samples are used during verification and validation, that use is documented and explained instead of left implicit in a result. Results go into the certification package without inappropriate modification, which is the point of independence: the assessor’s judgement reaches the reader as the assessor wrote it. The cadence follows the certification type and the class. On 20x at Class B and above, every Key Security Indicator goes through a FedRAMP independent assessment at least once a year; at Class A the obligation is instead to meet the expectations of the underlying alternative security framework as part of persistent independent verification and validation. On Rev5, the controls FedRAMP names go through an independent assessment at least once a year, every applicable control is assessed across a three-year cycle without needing to fall in the same assessment, and any control that drew a negative finding last time goes into the next one. Including all applicable Rev5 controls in every assessment, rather than spreading them across the cycle, is the preferred approach.", "crosswalks": { "fedramp-rules-2026": [ "IVV-CSO-FIA", "IVV-CSO-SEI", "IVV-CSO-SEE", "IVV-CSO-ICP", "IVV-CSO-DUS", "IVV-CSO-STE", "IVV-CSX-AIA", "IVV-CSF-AIA", "IVV-CSF-MCA", "IVV-CSF-ACF", "IVV-CSF-PCA" ] } }, { "key": "fedramp-significant-change-notification", "name": "FedRAMP significant change notification", "description": "Every potential significant change is evaluated first to work out which type it is, because the type decides what has to be told to whom and when, and auditable records of those evaluations are kept and handed to FedRAMP on request. Every notification carries at least the information FedRAMP requires, is published in both human-readable and machine-readable form along with its audit records, and the previous twelve months of notifications stay available alongside the certification data so an agency can see the history rather than only the latest entry. The three types are treated differently and the difference is the substance of the control. A routine recurring change is exempt and no formal notification is filed for it, so the channel is not filled with noise. An adaptive change is notified to all necessary parties within ten business days of being finished, with the detail the rule requires. A transformative change is notified four times over its life: initial plans at least 30 business days before it starts, summarizing the likely security impacts; final plans at least ten business days before it starts, updating everything sent earlier; a notification within five business days of finishing; and a notification within five business days of completing its verification, assessment or validation, again updating what went before. Updated service documentation reflecting the change is published within 30 business days of finishing it. Where human validation is needed, FedRAMP recommends engaging a third-party assessor to review the scope and impact before the change starts, limited to the security decisions that actually need human judgement, and this control adopts it.", "crosswalks": { "fedramp-rules-2026": [ "SCN-CSO-EVA", "SCN-CSO-MAR", "SCN-CSO-INF", "SCN-CSO-HIS", "SCN-CSO-HRM", "SCN-ADP-NTF", "SCN-RTR-NNR", "SCN-TRF-NIP", "SCN-TRF-NFP", "SCN-TRF-NAF", "SCN-TRF-NAV", "SCN-TRF-UPD", "SCN-TRF-TPR" ] } }, { "key": "fedramp-security-decision-record", "name": "FedRAMP Security Decision Record", "description": "A Security Decision Record is supplied in both human-readable and machine-readable form, covering everything the rule requires for each applicable FedRAMP rule, and carrying the basic metadata FedRAMP requires: its version, and the date, time and source of the last update. It is where the organization states, rule by rule, the decision it took and why, which is what lets a reader assess the service rather than only confirm that documents exist. What it must contain follows the certification type and the class. On Rev5 it carries short, plain, high-level summaries for each applicable Rev5 control, covering what the rule requires of each. On 20x it carries the same kind of summary for each applicable Key Security Indicator, and historical metrics beside them: optional at Class A, and from Class B a summary of each metric over the past 30 days and up to the past year where available, with Class C adding all daily metric data up to the past year. Class D must significantly supersede those lower-class minimums, and FedRAMP is setting the specifics during the 20x Phase 4 Pilot rather than having published them. Summaries are written to be read: short and plain is the requirement, so a record padded into unreadability satisfies the letter and defeats the purpose.", "crosswalks": { "fedramp-rules-2026": [ "SDR-CSO-FRR", "SDR-CSO-MTD", "SDR-CSX-KSI", "SDR-CSX-KMT", "SDR-CSF-CTF" ] } } ] }