KSI-CMT-RMVRedeploying vs Modifying

The telemetry proves a configuration is being enforced and drift corrected — it does not prove the enforced content IS your approved baseline. That the association's SSM document encodes the hardened settings you baselined (CIS/STIG content, approved through your change process) is the human judgement half; keep the document version and its approval record alongside this output. Two limits to state plainly: EC2_INSTANCE_MANAGED_BY_SSM does not flag a stopped instance whose agent is running, and this whole recipe is EC2-only — container images, Lambda, and managed-service settings need their own baseline evidence. CM-08 inventory is a separate recipe, not this one.

This proves the inventory is machine-maintained and current (CM-08.01, and the automated-currency half of CM-02.02) — it does not prove the inventory is complete. Config sees only supported resource types, only in the regions and accounts where a recorder runs, and only within the recording group you configured; unsupported types, an un-recorded region, on-premises hosts, SaaS components and in-container software are invisible here and need their own source. SSM Inventory covers only managed nodes with a running agent and an inventory association, collects no more often than every 30 minutes, and the console's Inventory cards hide stopped and terminated nodes even though the API still returns them. The accountability attributes CM-08 asks for — system owner, function, criticality — live in your tags or CMDB, not in a resource count, so join them before calling this an inventory. Substitute your real instance id. Detecting unauthorized components (CM-08.03) is a different question; the prohibited-software half is in the least-functionality recipe.

CloudTrail and Config prove a change was recorded and is reconstructable — actor, time, parameters, and the before/after configuration state — which is CM-03's record-retention and monitoring half. They do not prove the change was proposed, reviewed and approved before it happened; that decision lives in your CCB or ticketing system and has to be joined by ticket or change id. State the retention limits plainly rather than implying full history: lookup-events reaches back only 90 days and returns management (and Insights) events only, so anything older must be read from the trail's S3 objects or a CloudTrail Lake event data store, and get-resource-config-history honours your Config retention period (30 days minimum, up to 7 years) but each call spans at most 7 days, so a long window needs paging by time. Substitute your real resource type, resource id and time window. Change Manager has also been closed to new customers since 2025-11-07, so treat that command as available only if you were already signed up. Whether the post-change configuration is still compliant is a different question answered by the Config rule recipes.

These prove the negatives you asserted and hand the reviewer the real installed-application set — they do not prove least functionality. That the functions, ports, protocols and services still enabled are the minimum necessary is a judgement against your documented essential-capability list, and CM-07.01's periodic review is a decision someone makes and records, not an API result; keep the review record next to this output. Both rules are only as strong as their parameters. RESTRICTED_INCOMING_TRAFFIC defaults to blocking TCP 20, 21, 3389, 3306 and 4333 — set blockedPorts to your real denylist or you are testing AWS's defaults, not your policy. EC2_MANAGEDINSTANCE_APPLICATIONS_BLACKLISTED needs exact application names (no wildcards, and the name differs per distro) and evaluates AWS::SSM::ManagedInstanceInventory, so a node with no running agent or inventory association is simply not evaluated rather than flagged — pair it with the inventory recipe's coverage check. Security-group ingress deliberately overlaps the SC-07 boundary recipe: there it proves boundary protection, here it proves unnecessary ports are closed.

The trap in SI-3 is reading GuardDuty Malware Protection as antivirus. It is not a scheduled sweep of your file systems. A GuardDuty-initiated scan fires only after GuardDuty has already produced a finding indicative of malware on that resource, at most once every 24 hours per resource, and it works agentlessly against snapshots of the attached EBS volumes — so an empty describe-malware-scans list is the expected steady state of a healthy estate and proves nothing about coverage. The two enablement reads prove capability; the scan list proves exercise; neither proves protection. Coverage has a second silent hole: the global GuardDutyExcluded:true tag and your own inclusion or exclusion scan-option tags make GuardDuty initiate a scan and then skip it, so read the scan options next to the tag inventory or a deliberately excluded estate looks like a clean one, and Fargate workloads under EKS or ECS are not scanned at all. Malware Protection for S3 is the closest thing here to SI-3's entry-point requirement — it scans each newly uploaded object and each new version in a configured bucket — but it covers only buckets with an active plan, in the same Region as the plan, in your own account (a delegated GuardDuty administrator cannot enable it on a member account's bucket), and when run independently of GuardDuty there is no detector, so malware produces an EventBridge event, a CloudWatch metric and the optional object tag rather than a GuardDuty finding. What no command here produces is the rest of SI-3: signature or engine currency, since AWS operates the scan engines and exposes no version for you to attest to; periodic full scans; false-positive handling; and the documented response when malicious code is found. Rate those from the plan and the incident record, and keep these reads as the machine half of the answer.

CM-5 asks for physical AND logical access restrictions associated with changes that are defined, documented, approved and enforced. This recipe reaches one adjective and one verb. The adjective it does not reach is PHYSICAL. No AWS API returns anything about physical access to the hardware a change is made on; under the shared responsibility model that half belongs to the IaaS provider and is inherited — read it from the provider's own authorization package and the FedRAMP customer responsibility matrix, not from this output. A collection that presents these six calls as CM-5 evidence without saying so has answered half a control and labelled it whole. The verb it does reach is ENFORCE, and it reaches it properly: an SCP is not a description of a restriction, it is the restriction, evaluated by AWS on every request from every member account, and list-targets-for-policy is the difference between a policy that exists and a policy that applies to something. Two gaps keep this partial, not one. The first is approval — that the enforced set IS the documented and approved set is a comparison against a change-management record, and no call returns it. The second is subject matter, and it is the easier one to miss: the assertions below show THAT a customer-authored SCP is enforced, never WHAT it restricts. An SCP denying mechanicalturk:* satisfies every clause here exactly as well as one denying ec2:ModifyInstanceAttribute. The fourth call exists to close that by putting the policy document in the evidence — Content is returned as a JSON string and must be parsed — but no assertion can grade a policy document, so the phrase that makes this CM-5 rather than AC-3, 'associated with changes', stays a human read. Both gaps are reconciliations against your own records; the reconciliation is the CM-5 artifact and this output is the column it is reconciled against. Four ways this evidence is vacuous if it is read naively. Three are behaviour AWS documents in as many words; the fourth is an inference from a field being a list, flagged as such rather than dressed up as a citation. A policy type that has never been enabled is ABSENT from Roots[].PolicyTypes rather than present with a Status of DISABLED — the enum has no such value — so a clause of the form 'every SCP policy type entry is ENABLED' is true over an organization where SCPs were never turned on at all, which is why one assertion tests that the entry exists before another reads it. AWS attaches the managed FullAWSAccess policy to EVERY root, OU and account when it is created, so both a non-empty Policies[] and a non-empty Targets[] are the default state of a working organization rather than a restriction anyone wrote — which is why one assertion counts only the AwsManaged false subset, and why calls four and five are bound to a customer-authored policy id instead of any policy id. FeatureSet CONSOLIDATED_BILLING makes SCPs unavailable outright, so on such an organization every policy in the list is inert. And an SCP attached to nothing returns an empty Targets[]: that one AWS does not state, it follows from Targets being a list, and the assertion that rests on it should be read as an inference. The scope edge that matters most to an assessor is that SCPs do not restrict the management account. AWS states this three times on its own page and lists it first among the tasks SCPs cannot restrict: SCPs affect only member accounts, including member accounts designated as delegated administrators, and they have no effect on users or roles in the management account. The account with the broadest reach over the organization is the one account this evidence says nothing about, and its change restrictions have to come from identity-based policy and permission boundaries inside it — which is what the sixth call collects, and why the sixth call has to be run there. SCPs also do not affect service-linked roles at all, and they do not affect principals from accounts outside the organization even when a resource-based policy in your account grants those principals access. Read an SCP for what it is: a ceiling, never a grant. AWS is explicit that no permissions are granted by an SCP and that effective permissions are the intersection of what the SCP allows with what identity-based and resource-based policies allow — a principal with no IAM permissions has no access under the most permissive SCP in the world. Where a permissions boundary is also present, AWS documents that the boundary, the SCP and the identity-based policy must ALL allow the action, which is why the sixth call is collected beside the first five rather than instead of them. One failure mode worth writing into the assessment because it is silent and total: disabling the SCP policy type in a root automatically detaches every SCP from every OU, account and organization in that root, and re-enabling it does not restore the attachments — the root reverts to FullAWSAccess alone and the previous attachments are lost and not automatically recoverable. After such an event list-policies still returns every authored policy, unchanged, while nothing is enforced anywhere. The Roots[].PolicyTypes reading and the Targets[] reading are what separate those two worlds, and a collection that skips them cannot tell them apart. The permissions-boundary assertion is scoped by your own tagging rather than written as a claim over the account, for the same reason as in the AC-02 (02) recipe: no AWS call knows which of your roles are supposed to be the change authorities. It passes without saying anything on an estate that tags none, so treat the tagging standard as a written control with a manual sample rather than as coverage. What actually happened, as opposed to what was permitted, is a different recipe: CloudTrail's non-read-only event history, collected under CM-03 alongside the Config resource timeline and the Systems Manager change-request records. This one is about the restriction; that one is about the change.