Crosswalk pair
ESG Essentials and FedRAMP Rev5 Class C, control by control
4 canonical controls in Keel’s library satisfy clauses of both ESG Essentials and FedRAMP Rev5 Class C. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
The overlap
What the two libraries have in common
Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.
4
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
37
In Keel’s library for ESG Essentials
11% of them also map to FedRAMP Rev5 Class C.
64
In Keel’s library for FedRAMP Rev5 Class C
6% of them also map to ESG Essentials.
19
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
ESG Essentials 11%
4 controls of 37 in Keel’s library for ESG Essentials also map to FedRAMP Rev5 Class C.
-
4 controls of 64 in Keel’s library for FedRAMP Rev5 Class C also map to ESG Essentials.
The mapping
Controls that satisfy both
Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.
| Canonical control | ESG Essentials clauses | FedRAMP Rev5 Class C clauses |
|---|---|---|
| Information security policy 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. | G.9 | PL-1 |
| Respect for property & intellectual property rights 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. | G.13 | CM-10 |
| Third-party / vendor risk management 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. | G.7, E.7 | 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 |
| Security awareness training 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. | S.5 | AT-1, AT-2, AT-2(2), AT-2(3), AT-3, AT-4 |
Beyond the pair
Where else this work counts
A framework is lit when a shared control above also maps to it. Unlit means none of them do, which is an absence rather than a judgment about that standard.
Also reached by these 4 controls
- AI Governance Essentials not reached
- Amazon Appstore Child-Directed Apps not reached
- Apple App Store Kids Category not reached
- CIS Critical Security Controls also reached
- COPPA also reached
- EU AI Act not reached
- FedRAMP 20x also reached
- FedRAMP Consolidated Rules not reached
- FedRAMP Rev5 Class B also reached
- FedRAMP Rev5 Class D also reached
- GDPR also reached
- Google Play Families not reached
- HIPAA also reached
- ISO 9001 also reached
- ISO/IEC 27001 also reached
- ISO/IEC 42001 not reached
- NIST AI Risk Management Framework not reached
- NIST Cybersecurity Framework also reached
- NIST SP 800-171 also reached
- NIST SP 800-53 also reached
- PCI DSS also reached
- PIPEDA also reached
- SOC 2 also reached
- SOX (Sarbanes-Oxley) Section 404 also reached
- US Employment Law - Federal Baseline not reached
Nearby pairs
- FedRAMP Rev5 Class C and FedRAMP Rev5 Class D 64 shared controls
- FedRAMP Rev5 Class C and NIST SP 800-53 60 shared controls
- FedRAMP Rev5 Class C and ISO/IEC 27001 53 shared controls
- FedRAMP Rev5 Class C and FedRAMP Rev5 Class B 50 shared controls
- FedRAMP Rev5 Class C and NIST SP 800-171 40 shared controls
- FedRAMP Rev5 Class C and CIS Critical Security Controls 34 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, FedRAMP Rev5 Class C mostly lights up controls you already built for ESG Essentials. You’re not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That’s the whole idea behind collect once, comply everywhere.
Next step
Add FedRAMP Rev5 Class C to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.