A contact form should have a small operating record that explains why it exists, what it collects, where submissions go, who owns each dependency, and how to verify it. The document is useful only if another authorized person can diagnose a failed submission without guessing or exposing customer messages. Keep secrets out of the runbook and link to the approved secret manager instead.
Record purpose and data boundaries
Start with the page URL, form name, business purpose, intended audience, and the action a successful submission should trigger. List every field with its label, type, required or optional status, accepted format, maximum length, and business reason. Identify any sensitive or regulated data that must not be requested. Record the privacy notice shown to users, consent behavior where applicable, retention period, deletion owner, and who may access submissions.
W3C's forms tutorial recommends asking only for information required to complete the process and describes labels, instructions, validation, and clear success or error notifications as core form practices (W3C Forms Tutorial). Turn those principles into explicit acceptance criteria: every control has a visible, associated label; required fields are identified without relying on color alone; errors explain how to correct the problem; and a successful send produces a clear confirmation.
Map the complete delivery path
Document the browser endpoint, application handler, spam or bot control, queue or automation, email or CRM destination, sender identity, reply-to behavior, and fallback. For each component, name the service owner, technical owner, billing owner, account owner, renewal date if relevant, and approved support route. Do not copy API keys, SMTP passwords, recovery codes, or private mailbox contents into the document.
Add a simple flow such as page to server validation to spam control to storage to notification to assigned responder. State which system is the system of record and how duplicate submissions are detected. If the form can fail after showing success, document the acknowledgment boundary precisely so operators know whether a user was promised delivery before the message was safely stored.
Document validation and security controls
For each field, record both syntax rules and business meaning. OWASP recommends validating syntax and semantics, defining what is accepted, enforcing request and parser limits, rejecting invalid requests clearly, and validating on the server even when the browser performs the same checks (OWASP Input Validation Cheat Sheet). Also record output encoding, parameterized database operations, authorization, rate limits, anti-automation controls, attachment restrictions, and log-redaction rules as separate controls; input validation does not replace them.
Keep a versioned test matrix with valid submissions, each required field omitted, invalid formats, maximum lengths, unusual but legitimate names, keyboard-only use, screen-reader labels, spam-like content, repeated submissions, dependency outage, and delivery failure. Test only with authorized synthetic data. A pass must confirm the stored submission, notification, assignment, and user-facing result, not just the appearance of a success message.
Assign ownership and change authority
Name one accountable business owner and one operational maintainer. Define who may change fields, routing, retention, spam controls, sender identity, or integrations; which changes need review; and how to roll back. Include an emergency contact for suspected data exposure or unauthorized routing. If an external vendor controls part of the path, record the tenant or account identifier, contract owner, export method, and support escalation without including credentials.
Maintain a change log with date, requester, approver, exact before-and-after setting, reason, test evidence, deployment reference, and rollback result. Review the form after site releases, mailbox changes, CRM changes, domain or DNS changes, and staff transitions.
Keep a repeatable verification checklist
At a defined interval, submit an authorized synthetic message from a clean browser. Confirm field labels and instructions, client and server validation, privacy notice, spam handling, storage, notification, responder assignment, reply path, mobile layout, keyboard operation, and deletion workflow. Record the test timestamp and evidence location without retaining more personal data than necessary.
A good runbook finishes with known limitations, open risks, the next review date, and the person who accepted the current configuration. That turns the contact form from an invisible dependency into an owned, testable service.
Sources
- Forms Tutorial — World Wide Web Consortium Web Accessibility Initiative
- Input Validation Cheat Sheet — OWASP Foundation