WISP proof belongs in the work queue

A written information security plan is easy to treat like a file in a folder: important, necessary, and still separate from the work a tax office does every day. That is the mistake. For a small office, a WISP becomes useful when the controls create visible work: who reviewed the risk, who owns the next step, what changed, what evidence exists, and what still needs attention before the next client touch.

The operational implication

IRS Publication 4557 frames data security as an ongoing responsibility for tax professionals, not as a one-time document. The IRS WISP guide gives offices a starting structure for writing a plan. The FTC Safeguards Rule points in the same direction for covered financial institutions: identify risks, design safeguards, monitor service providers, train staff, and adjust the program when the facts change. The practical point for an owner is narrow: if the office cannot see the work, the plan will live outside the season instead of inside it.

Source anchors: https://www.irs.gov/pub/irs-pdf/p4557.pdf, https://www.irs.gov/pub/irs-pdf/p5708.pdf, https://www.irs.gov/newsroom/tax-professional-tips-for-creating-a-data-security-plan, https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know.

What the owner should see

A useful WISP workflow should not ask the owner to remember every control. It should show a small set of states. Planned means a control or review is on the calendar. In review means the office is checking whether the control still matches reality. Approved means the owner accepted the action. Verified means proof exists. Manual rescue means the control needs human judgment because the evidence is missing, stale, or ambiguous.

That state model matters because a small-office failure does not have to start as a dramatic event. It can start as a loose end. A new seasonal preparer gets access but the offboarding checklist is not updated. A vendor changes its login policy but nobody records the change. A client sends a document through the wrong channel and the staff member fixes it once, but the office never updates the intake instructions. Each item is small. Together they make the WISP hard to prove.

A scan anchor for the Monday review

Use a ten-minute Monday review. Open the queue and sort by risk, deadline, and owner. Look for four things: controls with no owner, controls with no proof, controls attached to a vendor or tool that changed, and controls that depend on one person remembering the next step. The owner does not need a long meeting. The owner needs a visible list where every control has a next action or a reason it is waiting.

A practical example: the office decides that client document requests should not move through personal text messages. That decision becomes real only when the queue shows the steps around it. Update the intake script. Confirm the client upload link. Train the seasonal preparer. Save the client-facing wording. Capture proof that the process was reviewed. If one of those steps is missing, the WISP is not finished for that control.

Where automation helps and where it should stop

Automation can help draft checklists, route reminders, surface stale items, and package evidence. It should not approve its own work. Automated checks can confirm whether a package has the right structure, and separate automated checks can review claims, sources, language quality, and unsupported product language. The owner still decides whether the action is right for the office. That division keeps the system useful without pretending that compliance judgment can be delegated to a script.

The same pattern applies to marketing content. A blog draft about WISP work should move through source gathering, brief, draft, design, requirements, accuracy, owner approval, publishing, and verification. If a chart is required, it should be specified before approval. If a source is required, it should be attached before approval. Once a post goes live, the office should keep a publication-evidence checklist: the live URL, a screenshot, a CTA/UTM check, a media-render check, and a timestamp.

Checklist before the item is done

• Does this control have one owner, not a group label?
• Does the next action describe the actual office behavior, not a policy slogan?
• Is there proof attached: screenshot, signed note, reviewed template, vendor setting, or training record?
• Is the CTA or client-facing instruction the same one the office will actually use?
• Is the item waiting on owner judgment, staff action, vendor response, or client behavior?

What not to count as proof

A statement in the plan is not proof by itself. A memory that somebody checked a setting is not proof. A message inside one staff member's phone is weak proof because the office cannot see it when that person is out. A screenshot without date, context, or owner can also become weak proof because nobody knows why it was captured. The queue should make the evidence useful later, not only comforting in the moment.

Better evidence is tied to the action. If the office reviewed access, the record should show which access list was checked and who accepted the result. If the office updated a client instruction, the record should show the exact wording and where the client sees it. If the office changed a vendor setting, the record should show the vendor, setting, date, and reviewer. The point is not to create paperwork for its own sake. The point is to make the office's security work reconstructable.

A small-office starting point

Start with five controls that already affect the season: client document upload, staff access, device lock screen, vendor login, and incident escalation. Put each one in the queue with one owner and one proof requirement. Do not start with a hundred-line checklist. Start with the five controls that would create the most confusion if the owner had to answer a client, a vendor, or a staff member tomorrow.

For each control, write the next action in office language. Not 'maintain safeguards.' Write 'confirm seasonal preparer access list before January onboarding.' Not 'monitor service providers.' Write 'record which vendor login settings changed and who reviewed them.' That phrasing makes the WISP easier for staff to follow because it names real work instead of abstract compliance language.

If the office already has a WISP, the next step is not rewriting it from scratch. The next step is mapping the plan to work that repeats. Which controls recur weekly, monthly, before season, after season, and when staff changes? Which controls need a screenshot, owner sign-off, or vendor note? That map turns the plan from static text into an operating calendar.

The owner should also separate routine proof from exception proof. Routine proof shows that expected checks happened. Exception proof explains what the office did when something did not match the plan. Both matter. A clean queue should show normal work without hiding the items that need judgment.

A WISP does not need to become another binder. It needs to become visible enough that a small office can manage it during tax season. The work queue is where that visibility belongs.

CTA: Review Intaxion tools for keeping approval, follow-up, and proof visible: https://www.intaxion.com/tools/wisp-generator