IT Security Controls Assessment: How to Test and Verify Controls

An IT security controls assessment is a structured check of whether your security controls exist, are designed correctly, and actually work. The assessor reviews documents and system settings, interviews the people who run each control, and tests the control directly. Each control is then recorded as satisfied or not, with the evidence that supports that call.

The work can be done by an internal security or audit team, by an outside assessor, or by a virtual CISO acting as your security lead. Most companies need one before a first SOC 2 or ISO 27001 audit, after a major change such as a cloud migration or acquisition, when a large customer or regulator starts asking detailed questions, and on a regular cycle after that, usually once a year with lighter checks in between.

What a controls assessment is, and what it is not

"Security assessment" gets used for several different jobs. Be clear about which one you are buying or running.

• Controls assessment. Asks: are the safeguards we say we have in place, and do they work? The output is a pass or fail per control, backed by evidence.
• Risk assessment. Asks: what could go wrong, how likely is it, and how bad would it be? The output is a ranked list of risks. Our security risk assessment guide covers that process. The two feed each other: the risk assessment tells you which controls matter most, and the controls assessment tells you whether those controls are reducing the risk.
• Penetration test. Asks: can a skilled attacker get in, and how far? A penetration test is one way to test certain technical controls, but it says nothing about whether access reviews happen or whether backups restore.
• Audit. A formal opinion issued by an independent party against a set standard, such as a SOC 2 report or an ISO 27001 certificate. A controls assessment is often the rehearsal for the audit.

The standards assessors actually use

You do not need to invent a method. Public frameworks already describe what to check and how.

NIST SP 800-53 Rev. 5: the control catalog

NIST SP 800-53 Rev. 5 is a catalog of security and privacy controls organized into 20 families, from access control to system and information integrity. One family, CA, covers assessment itself. In Rev. 4 it was called "Security Assessment and Authorization"; Rev. 5 renamed it "Assessment, Authorization, and Monitoring."

NIST SP 800-53A Rev. 5: how to assess a control

NIST SP 800-53A Rev. 5 is the companion document that explains how to test those controls. It is the clearest public description of assessment method, and four ideas from it are worth borrowing:

• Three assessment methods. Examine means reviewing, inspecting, or analyzing documents, settings, or activities. Interview means talking with the people responsible for the control. Test means exercising a mechanism or activity under set conditions and comparing what actually happens with what should happen.
• Four kinds of assessment objects. Specifications (policies, procedures, designs), mechanisms (the hardware, software, and firmware safeguards), activities (such as running backups or monitoring network traffic), and individuals (the people applying all of the above).
• Depth and coverage. Depth is how rigorous each examination, interview, or test is. Coverage is how many items you look at. Both are rated basic, focused, or comprehensive, and NIST says both should rise as the assurance you need rises.
• Two findings. Each determination is either "satisfied" or "other than satisfied." The second covers both a control that failed and one the assessor could not get enough information to judge. NIST leaves it to the organization to add severity levels on top.

NIST CSF 2.0: outcomes and gaps

The NIST Cybersecurity Framework 2.0, released in February 2024, organizes security outcomes under six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Govern is new in 2.0. The CSF does not prescribe how outcomes should be achieved, so it is not a test plan on its own. Its value in an assessment is the Current Profile and Target Profile: the assessment produces an honest Current Profile, and the gap to the Target Profile becomes your action plan.

CIS Controls v8.1: a prioritized starting point

CIS Controls v8.1, published in June 2024, contains 18 controls and 153 safeguards, with a new Govern function added in this version. The safeguards are split into three implementation groups. IG1 is what CIS calls "essential cyber hygiene," the baseline every organization should meet. IG2 builds on IG1 with additional safeguards, and IG3 covers the full set. For a 50 to 500 person company without a dedicated security team, assessing against IG1 first is a sensible way to scope a first pass. The safeguards are specific enough to test: 11.5, for example, calls for testing backup recovery quarterly, or more often, for a sample of in-scope assets.

SOC 2 and ISO 27001: design versus operating effectiveness

Audit frameworks split control testing into two questions. The AICPA describes a SOC 2 Type 1 report as covering the suitability of the design of controls, and a Type 2 report as covering both design and operating effectiveness. In SOC reporting, operating effectiveness is evaluated throughout a specified period, not on a single day. In practice that means the auditor picks samples from across the period (a handful of quarterly access reviews, a set of change tickets, new hire and termination records) and checks each one against what the control says should happen.

ISO/IEC 27001:2022 works the same way in spirit. Annex A lists 93 controls in four themes (organizational, people, physical, technological), and you record which ones apply in your Statement of Applicability. Certification auditors review your documented system first, then look for evidence that the controls you claim are running.

The lesson for your own assessment: a control that is well designed but has no records showing it ran will fail an audit. Test for both.

How to run an IT security controls assessment, step by step

1. Set scope and the yardstick. Name the systems, locations, business units, and data in scope. Pick one reference framework (CIS v8.1 IG1, SOC 2, ISO 27001, or a NIST 800-53 baseline) and stick with it. Write down the assessment period you are testing, such as the last six months.
2. Build the control inventory. List every control you claim, who owns it, and where it is documented. This is often where you find controls that exist only in a policy.
3. Write the test procedure for each control. For each one, decide which methods you will use (examine, interview, test), which objects you will look at, and how many. A short written procedure lets someone else repeat the test next year and get comparable results.
4. Request evidence up front. Send one evidence list to control owners with due dates. Ask for system-generated exports and dated records, not screenshots taken on the day you asked.
5. Test design, then operation. First confirm the control, as written, would address the risk. Then pull samples from the assessment period and confirm it actually ran each time. Where you can, test directly: try the login without MFA, restore the file, check the terminated user's account.
6. Record findings with evidence. For every control, record the result, the evidence reference, and for anything other than satisfied, exactly how the actual state differs from the expected state.
7. Rate, report, and track remediation. Assign severity, agree owners and dates with the business, and put open items on a tracked remediation plan. Retest closed items before you mark them done.

How to test common controls

Here is how we test controls that come up in almost every assessment, and what evidence proves each one works.

Control	How to test it	Evidence that proves it
Multi-factor authentication	Examine identity provider policy; test a login to email, VPN, and admin consoles with a test account	Configuration export showing MFA enforced for all users, list of any excluded accounts with approval, record of the test login being challenged
User access reviews	Sample reviews from the period; compare reviewer decisions with what changed in the system	Dated sign-off by the system or data owner, the list reviewed, and tickets showing access removed where the reviewer said to remove it
Joiner, mover, leaver	Sample terminated employees from HR records; check account disable dates in each key system	HR termination date against account disable timestamp, within the window your policy sets
Backups	Examine backup job configuration; test a restore of a sampled system or file set	Job success logs for the period and a restore test record showing what was restored, when, by whom, and whether it worked
Patching and vulnerability management	Compare scanner results against your remediation deadlines; sample critical findings	Scan reports over the period, tickets with open and close dates, and documented exceptions for anything past due
Change management	Sample production changes from deployment logs, then trace each back to a ticket	Ticket with approval recorded before deployment, and evidence the approver was not the person who made the change where your policy requires that
Logging and alerting	Examine log sources feeding your monitoring tool; trigger a test event	Source list matched to the asset inventory, and the alert produced by the test event with its response record
Security awareness training	Compare training completion data against the current employee roster	Completion report for the period, with follow-up on anyone overdue

Always sample from the system of record, not from examples the control owner picks. Pull every termination from HR, not just the accounts IT remembers disabling.

How to rate findings

Start with NIST's two outcomes, satisfied or other than satisfied, so the pass or fail call stays factual. Then add severity so leadership knows what to fix first. Three levels are enough for most companies:

• High. The control is missing or failing on a system that holds sensitive data or is exposed to the internet, and the gap could plausibly lead to a breach or a failed audit. Example: MFA not enforced on remote access.
• Medium. The control exists but works inconsistently, or a compensating control partly covers the gap. Example: access reviews done, but not every quarter.
• Low. A documentation or process gap with limited direct exposure. Example: the backup procedure is out of date, but restores test fine.

Rate on the risk the gap creates, not on how hard it is to fix, and link each finding to the risk it affects in your risk register.

What the assessment report should contain

Appendix E of NIST SP 800-53A lists the elements a security assessment report should include. Adapted for a commercial company, a useful report has:

• A one-page summary for executives: scope, framework, period, overall result, and the top findings in plain language.
• Scope details: systems and sites assessed, assessment dates, and who performed the work.
• A results table listing every control assessed with its status.
• For each control: the methods and objects used, the depth and coverage, the finding, assessor comments on the weakness, and a recommendation.
• Comparison with the previous assessment, where one exists.
• A remediation plan with owners, target dates, and severity for each open finding.

Keep the evidence itself outside the report. NIST recommends retaining it as an audit trail so it can be reused and the work repeated.

Frequently asked questions

How are security controls tested and verified?

Security controls are tested using three methods defined in NIST SP 800-53A: examining documents, configurations, and records; interviewing the people who operate the control; and testing the control directly, such as attempting a login without MFA or restoring a backup. Verification means comparing what actually happened over a period with what the control says should happen, using samples drawn from the system of record.

What is the difference between a controls assessment and a risk assessment?

A risk assessment identifies what could go wrong, how likely it is, and how much harm it would cause. A security controls assessment checks whether the safeguards meant to reduce those risks are in place and working. The risk assessment tells you which controls matter most. The controls assessment tells you whether those controls are actually reducing risk or only exist on paper.

How often should security controls be assessed?

Most mid-sized companies run a full controls assessment once a year, timed ahead of any SOC 2 or ISO 27001 audit. High-risk controls such as MFA, privileged access, backups, and patching deserve quarterly or continuous checks. You should also reassess after a major change, such as a cloud migration, an acquisition, a new critical vendor, or a security incident.

Can security control assessment be automated?

Partly. NIST SP 800-53A describes automated assessment as comparing a defined desired state with the actual state collected from systems, and points to NISTIR 8011 for detail. Configuration checks such as MFA enforcement, encryption, and logging settings automate well. Controls that depend on human judgment, such as access review decisions or incident handling, still need examination and interviews.

Who should perform an IT security controls assessment?

Someone independent of the controls being tested. That can be an internal audit or security team that does not operate the controls, an outside assessor, or a virtual CISO. Self-assessment by control owners is useful for preparation, but customers, auditors, and boards place more weight on results from someone who had no hand in building or running the control.

If you want a second set of eyes on your controls, BlueRadius runs security assessments against CIS, NIST, SOC 2, and ISO 27001, with findings and evidence you can hand straight to an auditor. For teams preparing for SOC 2 or ISO 27001, or that need ongoing security leadership through a virtual CISO, the assessment is usually where we start. If you are not sure where you stand yet, the free cybersecurity assessment is a quick way to find out.