Crosswalk pair
FedRAMP Rev5 Class C and NIST SP 800-53, control by control
60 canonical controls in Keel’s library satisfy clauses of both FedRAMP Rev5 Class C and NIST SP 800-53. 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.
60
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
64
In Keel’s library for FedRAMP Rev5 Class C
94% of them also map to NIST SP 800-53.
61
In Keel’s library for NIST SP 800-53
98% of them also map to FedRAMP Rev5 Class C.
252
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
60 controls of 64 in Keel’s library for FedRAMP Rev5 Class C also map to NIST SP 800-53.
-
NIST SP 800-53 98%
60 controls of 61 in Keel’s library for NIST SP 800-53 also map to FedRAMP Rev5 Class C.
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 | FedRAMP Rev5 Class C clauses | NIST SP 800-53 clauses |
|---|---|---|
| Governance & Risk | ||
| Acceptable use of information and assets 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. | AC-20, AC-20(1), PL-4, PL-4(1) | AC-20, AC-20(1), PL-4, PL-4(1) |
| Authorization to operate a system 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. | CA-6 | CA-6 |
| Contact with authorities & security communities 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. | SI-5 | SI-5 |
| Delegation of authority & segregation of duties 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. | AC-5 | AC-5 |
| 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. | PL-1 | PL-1 |
| Internal audit program 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. | CA-2(3), CA-1, CA-2, CA-2(1), CA-7(1) | CA-1, CA-2, CA-2(1), CA-7(1) |
| Resources for the management system 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. | SA-2 | SA-2 |
| 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. | CM-10 | CM-10 |
| Risk assessment & treatment 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. | RA-1, RA-3, RA-7 | RA-1, RA-3, RA-7 |
| Security performance measurement 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. | CA-7, CA-7(4) | CA-7, CA-7(4) |
| System security plan & control baseline 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. | PL-2, PL-10, PL-11 | PL-2, PL-10, PL-11 |
| Access Control | ||
| Access control policy 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. | AC-2(9), IA-2(5), AC-1, AC-2, AC-3, AC-6, AC-14 | AC-1, AC-2, AC-3, AC-6, AC-14 |
| External and federated identity acceptance 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. | IA-2(12), IA-8, IA-8(1), IA-8(2), IA-8(4), SA-4(10) | IA-2(12), IA-8, IA-8(1), IA-8(2), IA-8(4), SA-4(10) |
| Multi-factor authentication 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. | IA-2(6), IA-2, IA-2(1), IA-2(2), IA-2(8), IA-11 | IA-2, IA-2(1), IA-2(2), IA-2(8), IA-11 |
| Password & credential management 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. | AC-7, IA-1, IA-5, IA-5(1), IA-5(6), IA-6 | AC-7, IA-1, IA-5, IA-5(1), IA-5(6), IA-6 |
| Privileged access & administrative tooling 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. | AC-2(7), AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(9), AC-6(10), AC-17(4) | AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(9), AC-6(10), AC-17(4) |
| System use notification 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. | AC-8 | AC-8 |
| User provisioning & deprovisioning 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. | 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 | 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 |
| Data Protection & Privacy | ||
| Cryptographic key management 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. | IA-5(2), IA-7, SC-12, SC-17 | IA-5(2), IA-7, SC-12, SC-17 |
| Data classification & handling 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. | MP-3, RA-2 | MP-3, RA-2 |
| Data integrity verification 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. | SI-6, SI-7, SI-7(1), SI-7(7) | SI-7, SI-7(1), SI-7(7) |
| Data retention & secure disposal 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. | MP-6, SI-12, SR-12 | MP-6, SI-12, SR-12 |
| Encryption in transit & at rest 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. | SC-8, SC-8(1), SC-13, SC-28, SC-28(1) | SC-8, SC-8(1), SC-13, SC-28, SC-28(1) |
| Information transfer rules & agreements 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. | AC-21, CA-3 | AC-21, CA-3 |
| Review of publicly posted information 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. | AC-22 | AC-22 |
| Infrastructure & Operations | ||
| Application security requirements 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. | SC-23, SI-10, SI-11 | SC-23, SI-10, SI-11 |
| Asset inventory 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. | CM-8, CM-8(1), CM-8(3), CM-12, CM-12(1), SA-22 | CM-8, CM-8(1), CM-8(3), CM-12, CM-12(1), SA-22 |
| Change management 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. | CM-5(1), CM-5(5), CM-3, CM-3(2), CM-3(4), CM-4, CM-4(2), CM-5 | CM-3, CM-3(2), CM-3(4), CM-4, CM-4(2), CM-5 |
| Control of software on operational systems 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. | CM-7(2), CM-7(5), CM-11, SC-18 | CM-7(2), CM-7(5), CM-11, SC-18 |
| Logging & monitoring 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. | 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) | 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) |
| Malware protection 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. | SI-3, SI-8, SI-8(2) | SI-3, SI-8, SI-8(2) |
| Mobile device security 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. | AC-19, AC-19(5) | AC-19, AC-19(5) |
| Network security controls 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 devices connecting are authenticated 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. | 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 | 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 |
| Secure architecture & engineering principles 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. | PL-8, SC-2, SC-4, SC-39, SI-16 | PL-8, SC-2, SC-4, SC-39, SI-16 |
| Secure configuration & baselines 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. | CM-6(1), CM-1, CM-2, CM-2(2), CM-2(3), CM-6, CM-7, CM-7(1), CM-9, SA-5 | CM-1, CM-2, CM-2(2), CM-2(3), CM-6, CM-7, CM-7(1), CM-9, SA-5 |
| Secure software development 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. | IA-5(7), SA-3, SA-8, SA-11, SA-15, SA-15(3) | SA-3, SA-8, SA-11, SA-15, SA-15(3) |
| Security of assets off-premises 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. | CM-2(7) | CM-2(7) |
| Storage media lifecycle management 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. | AC-20(2), MP-1, MP-2, MP-4, MP-5, MP-7 | AC-20(2), MP-1, MP-2, MP-4, MP-5, MP-7 |
| Vulnerability management 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. | RA-5(3), SI-2(3), RA-5, RA-5(2), RA-5(5), RA-5(11), SI-1, SI-2, SI-2(2) | RA-5, RA-5(2), RA-5(5), RA-5(11), SI-1, SI-2, SI-2(2) |
| Web filtering 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. | SC-7(8) | SC-7(8) |
| Wireless network security 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. | AC-18, AC-18(1), AC-18(3) | AC-18, AC-18(1), AC-18(3) |
| Workstation & endpoint security 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. | SC-7(12), SI-4(23), AC-2(5), AC-11, AC-11(1), AC-12 | AC-2(5), AC-11, AC-11(1), AC-12 |
| Resilience & Continuity | ||
| Backups 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. | CP-6, CP-6(1), CP-6(3), CP-9, CP-9(1), CP-9(8) | CP-6, CP-6(1), CP-6(3), CP-9, CP-9(1), CP-9(8) |
| Business continuity & disaster recovery 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. | 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 | 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 |
| Incident response 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. | 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 | IR-1, IR-2, IR-3, IR-3(2), IR-4, IR-4(1), IR-5, IR-6, IR-6(1), IR-8 |
| Redundancy of processing facilities 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. | CP-7, CP-7(1), CP-7(2), CP-7(3), CP-8, CP-8(1), CP-8(2) | CP-7, CP-7(1), CP-7(2), CP-7(3), CP-8, CP-8(1), CP-8(2) |
| Security event reporting channel 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. | IR-7, IR-7(1) | IR-7, IR-7(1) |
| Third-party Risk | ||
| ICT supply chain security 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. | IR-6(3), RA-3(1), SR-1, SR-2, SR-2(1), SR-5, SR-8, SR-10, SR-11, SR-11(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) |
| Outsourced development oversight 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. | SA-10 | SA-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. | 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 | SA-1, SA-4, SA-4(1), SA-4(2), SA-4(9), SA-9, SA-9(2), SR-3, SR-6 |
| People & Culture | ||
| Disciplinary & sanctions process 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. | PS-8 | PS-8 |
| Personnel security (HR) 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. | PS-3(3), PS-1, PS-2, PS-3, PS-6, PS-7, PS-9 | PS-1, PS-2, PS-3, PS-6, PS-7, PS-9 |
| Remote and off-site working 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. | AC-17, AC-17(1), AC-17(2), AC-17(3), PE-17, SC-7(7) | AC-17, AC-17(1), AC-17(2), AC-17(3), PE-17, SC-7(7) |
| 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. | AT-1, AT-2, AT-2(2), AT-2(3), AT-3, AT-4 | AT-1, AT-2, AT-2(2), AT-2(3), AT-3, AT-4 |
| Physical & Environmental | ||
| Cabling security 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. | PE-4, PE-9 | PE-4, PE-9 |
| Equipment maintenance 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. | 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) | MA-1, MA-2, MA-3, MA-3(1), MA-3(2), MA-3(3), MA-4, MA-5, MA-6, SR-11(2) |
| Equipment siting & protection 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. | PE-5 | PE-5 |
| Facility environmental protection & utilities 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. | PE-13(2), PE-10, PE-11, PE-12, PE-13, PE-13(1), PE-14, PE-15 | PE-10, PE-11, PE-12, PE-13, PE-13(1), PE-14, PE-15 |
| Physical security 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. | PE-1, PE-2, PE-3, PE-6, PE-6(1), PE-8, PE-16 | PE-1, PE-2, PE-3, PE-6, PE-6(1), PE-8, PE-16 |
| Working in secure areas 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. | SC-15 | SC-15 |
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 60 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
- ESG Essentials also reached
- EU AI Act not reached
- FedRAMP 20x also reached
- FedRAMP Consolidated Rules also 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 also reached
- NIST AI Risk Management Framework also reached
- NIST Cybersecurity Framework also reached
- NIST SP 800-171 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 also reached
Nearby pairs
- FedRAMP Rev5 Class C and FedRAMP Rev5 Class D 64 shared controls
- NIST SP 800-53 and FedRAMP Rev5 Class D 60 shared controls
- FedRAMP Rev5 Class C and ISO/IEC 27001 53 shared controls
- NIST SP 800-53 and ISO/IEC 27001 52 shared controls
- FedRAMP Rev5 Class C and FedRAMP Rev5 Class B 50 shared controls
- NIST SP 800-53 and FedRAMP Rev5 Class B 49 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, NIST SP 800-53 mostly lights up controls you already built for FedRAMP Rev5 Class C. 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 NIST SP 800-53 to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.