Website security responsibility worksheet

Turn assumptions into named responsibilities

Complete this sheet with the people who manage your website. Use verified, needs work, unknown, or not applicable. “Verified” means someone showed the relevant evidence; it does not mean the system is secure in every respect. Explain every “not applicable.”

Keep this completed sheet private. Do not enter passwords, recovery codes, secret keys, customer records, private sign-in links, or screenshots containing them. Record roles and the location of approved instructions instead. This is a planning aid, not a penetration test or security certification.

Website / business:

Business decision-maker / provider / review date:

The customer function we most need to keep working:

1. Confirm account control

Ask the authorized account holder to demonstrate access. Do not collect or share their password. For each service, record the responsible role, whether multifactor authentication (MFA) is enabled, and whether a recovery process has been checked.

Service	Responsible role and provider	Access / MFA / recovery status
Domain registration and DNS
Hosting or website platform
Website administration
Business email
Forms, booking, or payments

Evidence date and approved instructions location:

Any former staff or vendor access still needing review:

Who will resolve it / due date:

Ask about phishing-resistant MFA where supported. CISA’s MFA guidance explains why an additional identity check matters. A missing MFA option should become a question for the provider, not an automatic “verified.”

2. Write down the maintenance boundary

Job	Who performs it	Evidence / next action
Platform, server, or hosting updates
Themes, plugins, integrations, or custom code
Urgent security fixes and unsupported components
Checking forms and key tasks after changes

Written maintenance scope or agreement reference:

How are failed updates escalated, and to whom?

What work is not included?

Use the FTC’s hosting and vendor questions to clarify shared responsibilities. Do not mark a job covered merely because another service is described as “managed.”

3. Record a recovery demonstration

Ask the provider to test safely away from the live site. Do not restore over production to complete this sheet.

What is backed up, including settings and uploaded files? _______
What is excluded, such as third-party bookings or inboxes? _______
Backup frequency and oldest retained copy:
How is a usable copy protected from loss of the normal account? __
Restore-test date / person responsible:
What was restored and actually checked?
Observed time to restore / limitations:
How much recent work would this backup miss?

Result: ☐ Demonstrated within stated scope ☐ Failed ☐ Not tested

Correction and retest owner / date:

CISA recommends protected backups and recovery testing. A scheduled backup job alone does not demonstrate that the business can recover.

4. Follow one form submission

Use a clearly identified, non-sensitive test submission only when authorized. Trace it through the form service, notification email, downloads, and any connected customer system.

Form / fields requested:

Which fields have no necessary business purpose?

Where do copies remain, and who can read them?

Retention rule / deletion owner / legal requirements to check: ___

Field to remove or storage question to resolve:

Owner / due date:

The FTC’s personal-information guide recommends limiting collection, access, and retention. Record the category of information here, never the customer’s actual data.

5. Rehearse a suspicious-message report

Fictional scenario: A message says the domain will be disabled today unless somebody signs in through its link. Do not send a simulated phishing message to staff without authorization; discuss the scenario instead.

Trusted route we will use to check with the provider:

Who receives the internal report, including after a mistaken click?

Backup contact if that person is unavailable:

Use NIST’s phishing guidance. If an incident is suspected, seek qualified help promptly. Preserve relevant evidence and ask counsel about applicable notification duties; this worksheet is not an incident-response procedure. FTC breach-response guide

6. Close the most important gap

The unresolved issue we will address first:

Named owner / next action / due date:

Evidence that will show the action is complete:

Next review date and events that trigger an earlier review: ______

Examples of review triggers include a provider change, staff departure, new form, new integration, or suspected incident. Do not total the checkboxes into a safety score.