Protect the records that keep a grooming day moving.

Start with an honest security boundary.

OpenDog is a web application for operating a grooming business. Security controls reduce risk; they do not make a device, employee, password, payment account, imported file, or internet connection impossible to compromise. OpenDog does not claim SOC 2, HIPAA, PCI certification, end-to-end encryption, or any other independent certification on this page.

• Use only the records the business is authorized to keep.
• Give each person their own account and the least access needed for the job.
• Keep computers and phones updated, locked, and out of shared personal accounts.
• Report suspected unauthorized access promptly and preserve useful details.

Protect sign-in, passwords, and recovery.

OpenDog stores passwords as one-way hashes using the application platform’s current password-hashing default. Sign-in checks the stored hash, limits repeated failed attempts, and regenerates the browser session identifier after a successful login. Password-reset and staff-invitation links use time-limited, one-use token records rather than sending a password by email.

• Use a unique password that is not shared with email, payment, or social accounts.
• Keep the account email current and protect that inbox with its own strong sign-in controls.
• Never send passwords, reset links, or invitation links in an ordinary client note or import file.
• Change the password and review active devices when an account may have been exposed.

See and close signed-in sessions.

An authenticated user can review current signed-in devices, see a device label, last-active time, and masked network context, then sign out another device or all other devices. Sessions close after two hours without activity and after 14 days overall. Changing a password signs out other sessions.

• Review the device list after staff, phone, or computer changes.
• Sign out an unfamiliar or retired device immediately.
• Do not leave a shared front-desk or van device signed in for the next person.
• A network label is supporting context-not proof of who used the device.

Keep browser sessions and form changes guarded.

Production HTTPS responses set HSTS and common browser-safety headers. On HTTPS, the OpenDog session cookie is marked Secure, HttpOnly, and SameSite=Lax. State-changing account and business forms use session-bound request tokens so a valid browser session must also present the expected form token.

• Use the https://opendogos.com address and do not ignore browser certificate warnings.
• HttpOnly keeps normal page scripts from reading the session cookie; it does not make an unlocked device safe.
• SameSite and request tokens reduce cross-site request risk; they do not replace careful access decisions.
• Security headers add browser boundaries without claiming every browser or extension is trustworthy.

Separate staff work by role and shop.

OpenDog carries the signed-in user’s role and shop account through protected workflows. Controllers check authentication and allowed roles before restricted actions. Customer, dog, appointment, service, route, payment, report, and other business queries are scoped to the active shop account, and platform-administration paths use a separate platform-admin check.

• Review manager, staff, and groomer access before sending an invitation.
• Deactivate access when a person leaves or no longer needs the workspace.
• Test each real role on the pages and actions it should-and should not-use.
• Shop scoping is an application control; businesses still need clean user ownership and offboarding.

Keep public requests outside the staff workspace.

Hosted request pages are customer-facing paths, not shortcuts into admin screens. A request collects service details for review and remains separate from a confirmed appointment until the business accepts the work. Owners should publish only the fields, services, policies, and contact details clients truly need.

• Do not ask clients to place passwords, full card details, or unnecessary private information in request notes.
• Review the dog, address, service, timing, and route fit before confirming.
• Keep internal staff notes and private operating details out of public page copy.
• Treat every submitted note as client-provided information that still needs human review.

Review files before importing business records.

CSV import is available inside an authenticated business account and opens a preview before save. The preview distinguishes new, matched, duplicate, invalid, and skipped rows. Import runs record outcome totals, and supported newly inserted records may be undoable when later activity has not made reversal unsafe.

• Move only the columns needed for the grooming workflow.
• Never place complete card numbers, security codes, passwords, private message archives, or unrelated personal information in a CSV.
• Use a small representative sample and verify the working records after import.
• Restrict temporary files and remove copies according to the business’s own retention policy.

Keep card handling with Stripe.

Supported online payments use Stripe-hosted or Stripe-controlled card-entry flows after the business completes the required setup. OpenDog stores the invoice, appointment, amount, status, and provider references needed to follow the payment workflow; it does not ask staff to type complete card numbers or security codes into ordinary OpenDog records. Incoming Stripe payment events must pass signature verification before payment updates are applied.

• Complete Stripe onboarding through the supported account path.
• Never collect complete card details in notes, email, text, support messages, or CSV files.
• Limit manual saved-card actions to authorized roles and the supported approval flow.
• Review receipts, balances, refunds, disputes, and payout questions against the Stripe account as well as OpenDog.

Use audit history for the actions it actually records.

OpenDog records audit events for selected account, staff, website, payment, billing, import, and platform operations. The available history can help explain who performed a supported action and when. It is not a complete recording of every click, screen view, conversation, or event outside OpenDog.

• Confirm which high-impact actions appear in the account before relying on them.
• Keep staff identities individual so recorded actions remain meaningful.
• Reconcile provider activity separately when Stripe, email, maps, or another connected service is involved.
• Preserve relevant exports, receipts, and support correspondence when investigating an incident.

Run a practical security check before launch.

Use a sample shop and the real devices the team will carry. Prove sign-in, role limits, session review, a public request, a small import, a payment handoff, an export, staff removal, and recovery before the live calendar depends on the account.

• Owner, manager, staff, and groomer can reach only the workflows they need.
• A public visitor cannot open an authenticated business area.
• An imported dog stays with the correct owner and shop.
• A card is entered only in the supported Stripe path.
• A lost or retired device can be signed out and a former team member can be deactivated.
• The owner knows who to contact and what details to gather when something looks wrong.

Workflow

Know who owns each part of the boundary.