2026-10-26 · By Todd Michael Gori
Writing Down What a Security Check Cannot See
A technical check produces evidence about one slice of a system. This article shows how to write the limits of that evidence beside the findings, using a small owned-lab example and a short reader exercise.
Why the limits belong in the report
A technical assessment answers a narrow question: what did this test observe, on this system, at this time? NIST Special Publication 800-115, a 2008 guide to planning and conducting technical security tests, addresses planning, conducting tests, analyzing findings and developing mitigation strategies. It also discusses the benefits and limits of assessment techniques instead of presenting any single test as a complete security program. That framing is useful for anyone who keeps notes from a learning exercise: the most valuable line in the notes is often the one that says what was not checked.
Readers tend to skip limitations because they feel like hedging. In practice they are what keep a finding from being misread. A note that says "permissions looked correct" invites the reader to assume far more than was examined. A note that says "permissions were inspected in one owned test directory; other directories, users and services were not examined" tells the next person exactly how far the observation reaches.
A worked example in an owned lab directory
Imagine a hypothetical learner who creates a disposable directory named lab-perms-practice inside their own home folder. They create three test files and two subdirectories, then inspect ownership and permission bits for each. Linux file access permissions distinguish the file owner, the group and others, and the read, write and execute bits mean slightly different things for regular files than for directories. The learner records what they see: one file is readable by everyone, one directory cannot be entered by the group, and the third file is only writable by its owner.
The useful part is the limitations section the learner writes next. It might read: scope was limited to one directory the learner owns; no system-wide files were examined; no other users were tested; the inspection reflects a single moment and will not catch later changes; interpretation of the results depends on the learner's own understanding of the bits. After the observations are recorded, the learner removes the test files and subdirectories and confirms the directory is gone. The cleanup step is part of the exercise, not an afterthought.
A short reader exercise
Pick a directory you own and that contains nothing important, or create a new one for this purpose. Write down three things: what you are testing, what you are explicitly not testing, and what would change your conclusion. Then create two or three files with different permission settings, inspect them, and write one sentence per file describing what the permissions appear to allow. Finally, write a sentence about what your notes cannot prove. Remove the test files when you finish.
Keep this exercise on systems you own or are explicitly authorized to test. The point is the habit of writing scope and limits, not the particular commands you use.
A checklist for limits notes
Before you finish any small assessment exercise, check the following.
First, confirm the scope in writing: which files, directories, accounts or services were examined, and which were not. Second, record the date and conditions of the observation, since a permission state is a snapshot. Third, state what the evidence does not cover, such as other users, network exposure or future changes. Fourth, note what would make you revisit the conclusion. Fifth, document cleanup, including which test files were removed and that the removal was checked. Sixth, reread the limits section and delete any sentence that claims more certainty than the evidence supports.
A good limits note does not make the exercise look weaker. It makes the result trustworthy, because a reader can see exactly what it stands for and what it leaves open.