The questionnaire is a starting point
Security assessments are most useful when they lead to a decision someone can own. A completed questionnaire is a record of answers. An improvement program also needs evidence, scope, responsibility and a way to determine whether the work changed the underlying condition.
The reviewed CSET README describes a free, guided assessment tool developed by CISA and Idaho National Laboratory for asset owners, with a focus on reducing critical-infrastructure risk. Its subject matter includes hardware, software, administrative policies and user obligations. That breadth is the central reason to review it: the documented process does not reduce an organization's security posture to a single device or software package.
What the documentation actually promises
CSET guides users through collecting facility-specific information. The README says it compares that information with relevant standards and regulations, assesses compliance, and provides recommendations drawn from cybersecurity standards, guidelines and practices. Where appropriate, recommendations are linked to improvement actions.
The documented scope includes both industrial control system and information technology architecture. It also emphasizes a consistent method for identifying, analyzing and communicating weaknesses and their consequences, as well as documenting the assessment process.
Those statements describe the tool's intended function. They do not establish that a particular answer is correct, that a control works in a particular facility, or that an organization has received an independent certification. This article makes no such claims about FLLC or anyone using the software.
An evidence model to add around the assessment
The following is a proposed FLLC workflow, not a feature claim about CSET's interface. For each material answer, maintain a small supporting record: what was assessed, the relevant boundary, who supplied the answer, what evidence supports it, when that evidence was collected and what remains uncertain.
For example, a synthetic assessment might ask whether a backup process is effective. A policy document and a completed recovery exercise answer different questions. The first describes an intended process; the second can record what happened during a particular test. Keeping those evidence types separate prevents a polished assessment package from implying more assurance than the material supports.
A useful outcome might be an accepted control, an improvement task, an evidence request or a documented exception. Those labels are suggested for the surrounding workflow. They are not presented as verified CSET field names or automated output states.
Keep the assessed boundary stable
Before comparing two assessments, write down whether they cover the same facility, systems and period. A later assessment might include more systems or a different standard selection. A change in the reported result could therefore reflect a change in scope rather than an improvement or deterioration.
For the proposed FLLC process, the assessment record would include a boundary statement that travels with exported findings. A reviewer should be able to distinguish a facility-level observation from an enterprise-wide conclusion. The README's emphasis on facility-specific inputs supports taking that boundary seriously; the record format itself is an editorial design proposal.
The same care applies to architecture. An ICS assessment and an IT assessment can share terminology while addressing different equipment and operating constraints. The article does not assume that one answer set can simply be copied between them.
Deployment choices need their own review
The reviewed README describes Windows standalone and enterprise options, as well as a Docker route for Mac, Linux or Windows users. It refers to a client-server architecture and additional installation guidance. Those are distinct deployment paths, not evidence of a native iPad application.
A deployment decision should be recorded before entering sensitive facility information. Who administers the host? Who may access an assessment? How are assessment files retained and recovered? These are proposed acceptance questions for the operator, not assurances supplied by this review.
The README's requirements list includes specific operating-system and runtime versions. This article deliberately does not turn that list into a claim that every listed combination was tested here. Match the chosen release to its own installation guidance and verify the actual deployment. The review did not install CSET, load a facility database or run a live assessment.
The improvement queue is the real follow-through
A proposed work item derived from an assessment should name the observed gap, supporting evidence, accountable owner, intended correction and acceptance evidence. A date alone is not an acceptance criterion. Neither is an automatically generated report.
For the synthetic backup example, the task would describe the recovery condition that needs to be demonstrated, the system boundary and the person authorized to accept the evidence. Once complete, the assessment record can point to that evidence rather than simply changing an answer to a more favorable value.
This proposed loop preserves the distinction between an assessment recommendation and a verified operational change. It also leaves room for a justified decision not to act immediately, provided that the decision and its owner are visible. None of this requires treating CSET as a vulnerability scanner or an autonomous remediation engine; the reviewed README describes a guided evaluation process.
Sources and review scope
Personfu/cset README, reviewed September 22, 2026. Selection came from FLLC's curated Starred Repositories catalog, not a verified current GitHub stars export. The evidence model and work queue are FLLC proposals. No certification, compliance determination or production deployment is claimed.