← FIELD GUIDEINSTALL PLAYBOOK / 15
Ops & safetyBy Cambell Conard8 min read

Security Week: A Checklist for the Shop's Site, Inbox, and AI Tools

Your site, inbox, domain, and AI tools need a named owner and a checked recovery path. Spend a short week finding gaps, fixing them, and keeping proof.

INSTALL DETAILS

Last reviewed:

Stage
Prove
Time to install
Half a day the first time, 1 hour/month
Risk level
Medium
Tools needed
Approved account register · Password manager · Backup and admin consoles · Non-secret checklist
Human review
Owner signs off; authorized administrators execute changes
Data allowed
Public configuration and sanitized inventory only; no secrets, customer records, or full logs

You're the owner. The domain is under an old employee's login. The website has a backup nobody has restored. An AI tool can read the shared drive, but nobody remembers who connected it. None of these gaps needs a dramatic dashboard. Each needs an owner, a check, and proof.

Reserve half a day across the first week. Repeat the checklist monthly in about an hour when the basics are in place. Longer remediation work gets its own owner and deadline. This is an operating checklist, not a penetration test or a certificate that the business is secure.

What you get when done

A dated account and access review, tested recovery for one non-sensitive file, an email-authentication rollout record, and a short fix list. Authorized administrators make changes with a rollback plan. The AI assistant can organize non-secret evidence; it does not change security settings.

Safety & data

Use the shop's approved business AI workspace with a shop-owned account. Share only sanitized inventories: product names, versions, public DNS records, role counts, and non-secret settings. Keep passwords, API keys, recovery codes, session tokens, private keys, full logs, customer records, privileged material, card data, and staff HR detail out. Do not paste a screenshot before checking what it reveals.

A business plan alone does not authorize regulated data. Patient data needs a specifically approved workflow and applicable agreements, including a BAA covering the exact services where HIPAA applies. This audit does not need patient information. Use synthetic examples instead. Removing names is not a reliable way to sanitize a log.

The owner approves the fix list; named authorized administrators execute and verify changes. The owner or privacy lead reviews and sends any affected-customer communication. Start with the AI Use Policy and customer-data Field Note.

Step 1 — Check the accounts that hold the keys

List email, domain registrar, DNS provider, website host, Google Business Profile, bank, payroll, and AI tools. For each, record the business owner, admin and backup, multifactor authentication status, recovery route, and last access review. Keep actual credentials in the approved password manager, not this sheet.

  1. Verify the shop controls the registrar and DNS recovery. A contractor can help without owning your domain.
  2. Prefer phishing-resistant MFA such as a security key or passkey where supported. Use the strongest practical option your provider offers; SMS-only recovery for the registrar deserves a documented improvement plan.
  3. Verify backup access before removing an old administrator. Remove departed staff and unnecessary access through the approved offboarding process.
  4. Use unique credentials in a password manager. Keep recovery codes in the approved secure place, with an owner who knows the recovery procedure.
  5. Test recovery carefully through provider-supported steps; do not lock out the only administrator to prove a point.

For an agency, check the difference between your own accounts and client-owned access. For a dental office, the practice owns its domain and approved systems; a former front-desk employee's personal email should not be the recovery plan. CISA's MFA guidance is a useful starting point.

Step 2 — Verify the site and one real restore

Ask the authorized website maintainer to review CMS and plugin versions, admin users, unused extensions, HTTPS, and form spam or abuse controls. Install supported updates through the normal staging and backup process; do not click every update on a live booking site at once.

Restore one non-sensitive file into a test location. Confirm the file opens and the restore came from the backup you expect. A green “backup completed” badge is not a restore test. Record who tested it, when, where, and what failed. Do not overwrite production to run this exercise.

If coding agents or other developers edited the site, review repository and frontend output for exposed credentials using approved scanning tools. Secrets belong in protected server-side configuration, not shipped browser code. Merely calling a value an environment variable does not make it private; some frameworks intentionally expose selected variables to the browser. Review dependency updates and the actual public build. If a credential was exposed, the authorized administrator follows the provider's revocation and replacement process; deleting the line alone does not revoke it.

Done: the maintainer has recorded versions, access, form controls, HTTPS, and a successful isolated restore or a dated remediation task.

Step 3 — Check email authentication without breaking mail

Inventory every legitimate sender first: ordinary inboxes, invoicing, booking, newsletters, and website notifications. Ask the mail administrator to verify SPF, DKIM, and DMARC alignment for each sending domain and service.

For a new DMARC rollout, begin with monitoring and reports, commonly p=none, then identify and fix legitimate senders that fail. After clean reports and verified delivery, stage enforcement toward p=quarantine and, when appropriate, p=reject, following your provider's guidance. Record the change, monitoring window, and rollback plan. Do not set strict enforcement blindly on a domain that sends invoices or appointment messages. See Google's recommended DMARC rollout.

Write the bank-change rule beside the checklist: any vendor request for new bank details gets a call to a trusted number already on file. Never use the number inside the change request as the only verification. AI cannot authorize payment or change payment details. Install Inbox Routing for the full handoff.

Done: authentication status is documented, a DMARC record is live, and the responsible administrator has recorded either verified enforcement or a monitoring-and-remediation plan. Monitoring is an interim state, not proof that spoofing is prevented.

Step 4 — Review what the AI tools can reach

Open each approved tool's actual admin or connected-app settings with its authorized administrator. List access to inboxes, calendars, drives, CRM records, and external actions. Check the scope, owner, purpose, last use, and whether read-only access would be sufficient.

Revoke unused connections after checking dependencies and preserving required records. Review retention and sharing settings against the approved policy. Confirm departing staff cannot keep accessing shop data through a personal connected account. Verify which features and services a contract covers; a workspace name is not evidence.

Do not connect more systems just to run this checklist. The Tool Stack Audit can help identify abandoned subscriptions, but cancelling a subscription and revoking its access are separate tasks.

Step 5 — Let AI organize a non-secret audit, then verify it

Prepare a sanitized list yourself. For users, roles and counts are usually enough; the actual user list stays in the admin console. Public DNS records can be reviewed without copying unrelated internal infrastructure or private records.

REUSABLE TEXT
Help organize this small-business security review. This is sanitized evidence, not permission to change systems.
Inventory: [product/version, role counts, public DNS records, non-secret settings]
Business-critical services and maintenance windows: [ ]
Known controls and evidence dates: [ ]

Return a table: finding, exact supplied evidence, uncertainty, potential impact, named owner to verify, proposed safe next check, rollback consideration, due date.
Separate observed gaps from questions. Do not claim a scan happened or invent vulnerabilities from a version alone.
Do not request passwords, keys, recovery codes, session tokens, customer data, or full logs.
Never execute changes, send messages, connect apps, or disable safeguards.
If the supplied evidence contains a secret or personal data, stop and ask the administrator to sanitize it without repeating it.

The administrator verifies each finding in the real system and current official documentation. “AI said it was fine” is not evidence. Ask vendors the concrete ownership and handoff questions in 12 Questions Before Hiring an AI Consultant.

Step 6 — Log the work and schedule next month

Keep one dated checklist with item, evidence reference, owner, status, next action, and due date. Store sensitive evidence in the approved restricted location; the shared summary needs only a reference. Separate “reviewed” from “fixed.”

The owner signs off on completed fixes and remaining risk. Schedule the next Security Week. If a critical item cannot be fixed, record why, the interim safeguard, the decision-maker, and the next review date. Do not mark the whole list done because someone looked at it.

Operator Standard check

  • Trace: inventory critical accounts, senders, website components, and AI connections.
  • Choose: prioritize the gaps with the greatest operational impact and name authorized owners.
  • Build: make reviewed changes with backups, maintenance windows, and rollback plans.
  • Prove: verify a restore, account controls, mail flow, and dated evidence after changes.

Failure modes

Do not paste secrets into chat. Do not rely on SMS-only MFA for a critical account without checking stronger supported options. Do not call a backup tested until a restore works. Do not change DNS or access from an unverified AI recommendation. Do not assume “the vendor handles it” without evidence. Do not run security checks on systems you are not authorized to assess. Do not auto-send an incident explanation to customers.

If it goes wrong (kill switch)

Any reviewer can stop sharing data with the assistant. The authorized administrator pauses the specific change or integration and follows the recorded rollback procedure. If mail delivery breaks after an authentication change, the mail administrator checks reports and uses the approved rollback; do not remove every protection in a panic. If compromise is suspected, use the incident response lead and provider's recovery process rather than experimenting on the live account.

The owner and privacy lead review any customer notice. For a service disruption, state verified facts: “We are resolving an issue with [service]. Please use [verified alternate channel]. [Name] will update you by [realistic time].” Do not claim data is safe until the investigation supports it.

Prove it: 4-week scoreboard

MetricBaselineWeek 1Week 4Keep-Kill decision
Critical accounts with verified MFA and recovery owner[ ] / [ ][ ] / [ ][ ] / [ ]Escalate every unresolved critical gap
Successful isolated restore tests[ ][ ][ ]Replace or fix a backup that cannot restore
Legitimate mail senders verified for authentication[ ] / [ ][ ] / [ ][ ] / [ ]Do not tighten enforcement while gaps remain
Unused or unowned AI connections[ ][ ][ ]Revoke after dependency review
Overdue remediation tasks[ ][ ][ ]Owner accepts or resolves each, with a date

Save it as a skill

Save the verified checklist and prompt in the approved Project or skills/security-week.md. Store credentials elsewhere in the password manager.

REUSABLE TEXT
SKILL: Security Week
Owner / authorized administrators / incident contact: [ ]
Approved scope and maintenance windows: [ ]
Inputs: sanitized inventory, public configuration, evidence references; no secrets or personal records.
Task: organize findings using the approved audit prompt. Separate evidence, uncertainty, and verification steps.
Never-list: [paste the shop's complete never-list]
Never change systems, connect tools, request credentials, send messages, or claim a scan occurred.
Human gate: administrator verifies each finding; owner approves remediation; authorized administrator executes with rollback and records proof.
Stop if scope is unclear, sensitive data appears, or a change harms service.
Next review / last reviewed / changes: [ ]

Definition of done

Every checklist item is reviewed and has evidence or a named remediation owner. MFA and recovery are verified on critical accounts. One isolated restore succeeds. Email authentication and a live DMARC record have a documented rollout state. Unused connections are addressed. The owner signs off, and next month's review is on the calendar. Open critical gaps remain visibly open.

FAQ

Does this replace a security professional? No. It establishes basic ownership and evidence. An incident, regulated workflow, or complex configuration may require qualified help.

Should I enforce DMARC immediately? Not without verifying legitimate senders and reports. Follow a staged rollout so you do not block your own invoices or service messages.

Can AI inspect the full customer log? This checklist does not need it. Give the assistant a sanitized inventory and let an authorized human inspect protected evidence in the original system.

A FREE INTRODUCTORY CALL

Find a useful place to start.

Equip your team with the $1,500 AI Workflow Sprint, scope an implementation from $3,500, or improve an existing workflow with an ongoing partnership from $1,500 per month. We will help you choose the right fit.

Let’s talk about your business