A developer wants to custom-script every control test on day one of a county IRM rollout. What approach should the implementer prefer first?
Select an answer to reveal the explanation.
Short Explanation
Day one is for flipping the built-in switches—attestations, indicators, item generation—not for a custom-code carnival. Scripting every test up front is like welding a new engine when the car already starts. Use configuration first; code only when the product truly cannot express the need.
Full Explanation
CIS-RC implementation favors configuring attestations, indicators, and item generation first, reserving custom code for true gaps after out-of-box patterns are exhausted. A developer who wants to custom-script every control test on day one of a county rollout creates cost, upgrade friction, and a bypass of the product’s designed operating model. Day one should flip built-in switches so control owners can attest and monitors can measure before anyone welds a custom engine. Writing CAD Script Includes for every test before any attestation or indicator is configured inverts configuration-first guidance. Replacing Policy and Compliance with a custom scoped app that bypasses entity scoping abandons the IRM framework municipalities bought. Disabling item generation so only manually coded tests can ever run rejects the platform’s association and generation patterns. Exam caveat: Risk and Compliance implementation is configuration-led; broad CAD scripting is not the CIS-RC core skill narrative. Operational check for the county: enable item generation for one scoped control objective, complete one attestation and one indicator without custom scripts, document any remaining gap that truly needs code, and only then open a development story.