1. Learn
Read Website & Domain SecurityCybersecurity Center
Small-business cybersecurity for websites, email, domains, and vendor trust.
Learn what to check, why it matters, and when website, email, DNS or admin-access issues need a vendor-ready fix order instead of more guessing.
Practical tools and plain-English guidance for owners who rely on branded email, booking tools, payment links and customer trust.
Start with your question
What brought you here today?
Choose the situation closest to yours. Start with the guidance or free check; human help is optional and depends on what you find.
Selected topic
Website and forms
Checking a website or planning a vendor handoff? Start with public HTTPS and browser-header signals, then identify who owns any fixes.
Start here
A simple learning path before you buy anything.
Use this page to understand the basics, run a safe public check, and decide whether you need a paid review, cleanup help, monitoring, or questionnaire support.
Understand your public risk
Start with your website, business email, account owners and the providers who can make changes.
Use the checklistCheck website, email, and domain basics
Use the free public check for a quick look at HTTPS, redirects, security headers, DNS, SPF, and DMARC indicators.
Run free public checkDecide what to fix first
Decide whether the evidence needs human review, a known issue needs cleanup, or existing fixes need ongoing oversight.
Choose the right next stepFree tool directory
Start with the tool that matches your question.
Choose by the question you need answered, not by a promise of an all-clear. Each tool gives a limited view of a specific area.
01 / Free tool
A useful first look
Free Website, Email & Domain Check
- Best for
- A first review of your business domain or a website handoff.
- Expected output
- A public-signal summary with explained findings.
What it checks and where it stops
Check defined public-facing signals before deciding what needs closer attention.
- Website reachability, HTTPS availability and redirects
- Common browser security headers
- Public MX, SPF and DMARC signals
Does not check: No malware, exploit, password or private-system testing. A strong result is not proof that the business is secure.
Next step: Confirm the responsible host or email provider; use a Security Snapshot if you need human interpretation and a fix order.
Understand website security basics02 / Free tool
Email & domain configuration
Business Email Trust Check
- Best for
- Email-platform changes, spoofing concerns or unfamiliar DNS records.
- Expected output
- Explained findings and printable technical evidence.
What it checks and where it stops
Review published email configuration without providing mailbox access or message content.
- MX, SPF and DMARC records
- Published MTA-STS policy, TLS-RPT and DNSSEC DS visibility
- DKIM records when you supply a known selector
Does not check: No mailbox inspection, universal DKIM discovery or delivery guarantee. Published records do not prove every message is signed or every policy operates correctly.
Next step: Inventory legitimate senders before changing records. Get interpretation first, or scoped cleanup for a confirmed configuration issue.
Understand SPF, DKIM & DMARC03 / Free tool
An owner-led checklist
Vendor Access & Ownership Check
- Best for
- Onboarding an IT provider, replacing a web vendor or documenting recovery.
- Expected output
- A printable checklist of owners and unresolved questions.
What it checks and where it stops
Identify ownership questions before someone leaves or an account becomes difficult to recover.
- Your answers about domain, DNS, hosting and workspace control
- Recovery methods, approved senders and former vendor access
- Backup responsibility and emergency provider contacts
Does not check: Self-reported answers, not independent account verification or a risk score. Do not enter credentials; answers remain in the current browser tab.
Next step: Verify gaps against provider records; request scoped help when transfers or several systems need coordination.
Plan a safer vendor handoff04 / Free tool
Browser-visible signals only
IP, DNS & WebRTC Connection Check
- Best for
- Comparing what this website sees before and after a VPN, Wi-Fi or network switch.
- Expected output
- A factual comparison and redacted summary or printout.
What it checks and where it stops
See what changes when your connection changes, and where browser-visible evidence stops.
- Request-visible public IP, IP version and approximate exit location when available
- Browser/device summary, page protocol and secure-context status
- Browser-exposed network estimates and optional WebRTC candidates
- Optional HTTP round-trip measurements to CyberBit's current hosting edge
- Before/after comparison of available signals
Does not check: No reliable DNS resolver data, definitive VPN or DNS-leak verdict, anonymity check, malware assessment or device-wide traffic view. No public STUN server is used. HTTP timing is not ping, packet loss or a speed test.
Next step: Compare results with the expected provider route. Request a scoped office network review if the difference needs investigation.
Understand DNS, VPN & WebRTC limitsUnderstand the boundary. No exploit testing, malware scanning or credential testing. Domain checks make public requests; the vendor checklist uses your own answers. Optional WebRTC candidates and comparison baselines stay in the browser tab, while normal connection requests reach the server. Read each tool’s privacy notes before using it. Read the Privacy Notice
What to check first
A practical small-business security checklist.
This is a plain-English starting point, not a full audit. It helps you organize website, email, domain, admin, and vendor questions before asking someone to make changes.
Write down the owner, the evidence and the next action. These are starting questions, not a complete audit or a substitute for reviewing the actual system.
Is the website reachable over HTTPS?
Does HTTP redirect visitors to HTTPS?
Are basic browser security headers present?
Are SPF and DMARC present for the sending domain?
Is DMARC only monitoring, or is it moving toward enforcement after review?
Do you know who controls DNS and the domain registrar?
Are admin/login pages intentionally public and protected?
Is MFA enabled for domain, email, website, and cloud administrator accounts?
Do you know who can change website, email, DNS, form, and payment-link settings?
Can you explain the setup to a client, vendor, insurer, or security questionnaire reviewer?
Have you tested an important backup and agreed a fix order with its owner?
Explainer directory
Plain-English guides behind the tools.
Use these explainers to understand results before asking a provider to make changes.
Security headers
Understand browser protections, who can change them, and why policies need testing against your forms and integrations.
TLS and certificates
Check HTTPS, certificate warnings and redirects, then take a clear question to the responsible website provider.
Email authentication
Review SPF, DKIM, DMARC, alignment, spoofing risk, and why email changes should be staged carefully.
WHOIS and domain ownership
Separate public registration clues from the account access, renewal and recovery details your business must confirm.
DNS and VPN privacy signals
Put VPN comparisons and browser-visible connection signals in context without treating them as a DNS-leak verdict.
Public IP, IPv4, IPv6, and CGNAT
Know what websites may see about your current connection and why VPN, proxy, mobile, and office networks can look different.
A closer look / connection visibility
What changes when you switch networks?
A browser can show useful evidence about its own requests. It cannot see every app, identify your configured DNS resolver reliably, or certify that a VPN protects the whole device.
The IP this request used
A public IP is the connection source this website sees. IPv4 and IPv6 can follow different routes; one result does not show every route your device supports.
An exit point, not your location
Approximate location appears only when hosting metadata provides it. It may describe an ISP, VPN, mobile or corporate exit, not your physical location.
Browser context, not device security
The browser/device summary, page protocol and secure-context flag describe this visit. Optional network estimates vary by browser and are not a speed test or a device-wide view.
WebRTC has a narrower view
ICE candidates are possible connection addresses. This optional check uses no STUN or TURN server, limiting public discovery. Private addresses and mDNS-obscured names are not automatically leaks.
Compare one change at a time
Save a baseline, switch VPN, Wi-Fi or hotspot, then compare. A changed IP confirms this request's exit changed; an unchanged IP may reflect the same exit or split routing. Neither proves VPN coverage or failure.
HTTP timing is a separate measurement
Optional round trips estimate response time to CyberBit's current hosting edge. They are separate from the before/after comparison, not ping, packet loss, bandwidth or an internet speed test.
Start on a known network, note the result, switch VPN, Wi-Fi or hotspot, then compare. An IP change is an observation—not a DNS-leak verdict, anonymity test or security guarantee.
Compare connection signalsWhat does this mean?
A finding is a starting point, not a verdict.
Read the observation, understand its limits, then choose a safe next step. Missing, unknown and failed are not interchangeable.
Email authentication & transport
SPF missing
What we observed
No SPF sending-authorization policy was returned for the checked name.
What it may mean
The domain's sending configuration needs confirmation with the email owner.
What it does not prove
This does not mean all mail is unauthenticated or that spoofing occurred.
Practical next step
List legitimate senders and confirm their sending domains with your provider before publishing a restrictive policy.
Review email authentication basicsDMARC missing
What we observed
No DMARC record was returned for the checked name.
What it may mean
A policy may be missing; the check does not perform complete inherited-policy discovery.
What it does not prove
This does not establish that no policy applies, that spoofing occurred or that messages are safe.
Practical next step
Ask the email owner to confirm inherited policy, lookup errors and legitimate SPF/DKIM alignment before changing enforcement.
Review public email signalsDMARC is monitoring-only
What we observed
The published DMARC policy uses p=none.
What it may mean
The owner is not requesting quarantine or rejection for DMARC failures; reporting can inform a staged rollout.
What it does not prove
This does not prove reports are configured or reviewed, or that receivers accept every failing message.
Practical next step
Review reports and legitimate sending streams before moving toward stronger policy; do not tighten it blindly.
Read DMARC in plain EnglishDKIM unknown or not checked
What we observed
A provider-confirmed DKIM selector was unavailable or was not checked.
What it may mean
The sending provider needs to identify the selector before a public-key lookup is useful.
What it does not prove
Unknown does not mean DKIM is absent. A public key alone would not prove outgoing messages are correctly signed.
Practical next step
Get the selector from your provider, then confirm signing and alignment using authorized message-level evidence.
Check a known DKIM selectorMTA-STS absent
What we observed
The check did not establish a usable published MTA-STS policy.
What it may mean
Mail-transport policy may be absent, incomplete or temporarily unavailable.
What it does not prove
This does not prove email traveled without encryption or establish how every sender behaves.
Practical next step
Confirm mail-server TLS support and policy ownership; coordinate any rollout and transport reporting with the provider.
Review public mail-transport signalsWebsite & domain signals
HTTPS or TLS issue
What we observed
The check could not confirm normal HTTPS behavior for this hostname.
What it may mean
DNS, certificates, redirects or hosting may need attention.
What it does not prove
This is not evidence of compromise or intercepted traffic.
Practical next step
Confirm the hostname and responsible host/CDN before interpreting other missing website controls.
Understand HTTPS & TLSA security header is missing
What we observed
A security header was not present in the checked response.
What it may mean
An appropriate browser protection may need configuration; relevance depends on the application.
What it does not prove
Absence does not prove exploitation, and every header is not appropriate for every application.
Practical next step
Ask the developer or host to review an appropriate policy and test forms, widgets and embeds before rollout.
Understand browser security headersDNSSEC not observed
What we observed
The tool did not observe a parent DS record for the checked domain.
What it may mean
Registrar and DNS-host delegation settings need confirmation.
What it does not prove
This is not a complete DNSSEC validation, encrypted-DNS check or DNS privacy verdict.
Practical next step
Confirm registrar and DNS-host support before coordinating DNSSEC. Incorrect delegation can disrupt resolution.
Review DNS ownership & changesIP, VPN & browser visibility
A WebRTC candidate is visible
What we observed
The browser exposed a possible connection address through WebRTC.
What it may mean
A local interface or another connection route may be visible.
What it does not prove
Private, mDNS-obscured or relay candidates are not automatically leaks; a different public address alone does not prove VPN failure.
Practical next step
Compare a public, non-relay candidate with the request-visible IP and expected route. A difference needs context, not an instant VPN-failure verdict.
Review connection visibilityIP changed after a network switch
What we observed
This website saw a different public IP after the change.
What it may mean
The observed request used a different exit address.
What it does not prove
This does not establish anonymity or show that every application uses the VPN.
Practical next step
Save a redacted comparison and confirm the exit matches your provider's intended setup.
Compare connection signalsIP did not change after a network switch
What we observed
This website still saw the same public IP after the change.
What it may mean
The intended route may use the same exit, or split routing may leave this browser request unchanged.
What it does not prove
An unchanged address alone cannot establish whether the VPN or network change failed.
Practical next step
Confirm which applications and routes the change was intended to affect; use the provider's diagnostic for that configuration.
Understand the comparison limitsApproximate location looks wrong
What we observed
Available hosting metadata shows an unexpected approximate exit location.
What it may mean
It may describe an ISP, VPN, mobile or corporate exit point; location databases can also be imprecise.
What it does not prove
An unexpected city alone is not evidence of compromise or your precise physical location.
Practical next step
Compare the expected network and provider before treating the location difference as a problem.
Understand public IP contextVendor access & recovery
Vendor or account ownership is unclear
What we observed
Your answers leave an ownership or recovery responsibility unconfirmed.
What it may mean
Account control and provider responsibilities need verification against records.
What it does not prove
A self-reported gap is not independent account verification or evidence of a breach.
Practical next step
Confirm administrators, billing, recovery and authorized responsibilities against provider records before removing access or transferring control.
Create a provider handoff checklistBefore changing a production setting, confirm the provider, owner and legitimate dependencies. In particular, do not copy a restrictive DNS, email or browser-header policy from a generic example.
Common problems by business type
Different businesses run into different security questions.
These are practical examples, not client claims or guarantees. Use them to decide where to start.
Dental or medical office
Patient-facing forms, online scheduling, email, and vendor portals often depend on multiple providers. Ownership confusion can slow down secure fixes and make insurance or vendor questions harder to answer.
Check public website and email signals first. Keep patient records out of public tools; confirm form and portal responsibilities with the provider.
Start with the free public checkLaw or accounting firm
Email spoofing, document sharing, client portals, and vendor questionnaires can create trust and evidence gaps. Clients may ask for clear answers about MFA, backups, email authentication, access, and provider controls.
Review DMARC and admin access first, then compare Security Questionnaire & Evidence Support if a client request is active.
View questionnaire supportContractor or local services business
A basic website, branded email, booking forms, and payment-change messages can all affect customer trust. Missing HTTPS, weak email authentication, or old vendor access can make scams and handoff problems more likely.
Use the public check for quick signals, then request Focused Remediation if fixes are already clear.
View cleanup serviceEcommerce or online store
Plugins, redirects, forms, checkout links, tracking scripts, and admin access can drift as tools change. A small website change can affect customer confidence, payment flow, and vendor handoff notes.
Review public signals and confirm who owns updates, backups and checkout changes. Use scoped implementation help for known issues.
Review coordinated cleanupNonprofit or community organization
Shared admin access, volunteer turnover, donation links, and old web vendors can leave ownership unclear. Clear access and recovery notes reduce disruption when people or providers change.
Start with domain, DNS, email, MFA, and handoff checks before any redesign or cleanup work.
View cleanup sprintStartup or vendor-facing business
Clients may ask for questionnaire answers before the security evidence is organized. Unsupported answers can create follow-up work and credibility problems later.
Gather evidence for the controls you actually operate. Use questionnaire support when answers, ownership or evidence gaps need clarification.
View questionnaire supportPut it into practice
Use the moment of change to get the basics right.
A short record of owners, evidence and next actions is often more useful than another unexplained score.
Onboarding IT or handing over a website
Make ownership explicit before access changes.
- Record the business owner, registrar, DNS host, website host and email provider.
- Confirm business-controlled billing, recovery methods and a protected backup administrator.
- Agree which vendor access ends, who can authorize changes, and how to restore a backup.
Switching email platforms or investigating spoofing
Keep legitimate mail working while you review authentication.
- Inventory every sender: mailboxes, forms, invoices, marketing and third-party services.
- Ask each provider about SPF, DKIM signing and alignment with your visible From domain.
- Review reports and test authorized mail before tightening DMARC or changing transport policy.
Preparing for cyber insurance
Separate controls you can evidence from work still planned.
- Gather current evidence for MFA, account ownership, backups and restore testing.
- Record who verified each answer and what is managed by an external provider.
- Ask your broker or insurer to clarify ambiguous wording; do not claim controls you cannot support.
Reference library
Practical guidance, one question at a time.
Go deeper when a question needs more context. Open a topic for practical checks, ownership questions, and when to ask for help.
Optional: find a specific term
Showing 28 of 28 topics.
Email SecurityBusiness Email SecurityRead practical stepsClose practical steps
Reduce the chance that criminals can impersonate your domain, abuse business email, or trick staff and customers.
Why it matters
Email compromise and domain spoofing can lead to invoice fraud, fake messages, and lost trust.
Who should review it
Businesses that send email from their own domain or rely on Microsoft 365 / Google Workspace.
What to check
- Check SPF, DKIM, and DMARC records
- Turn on MFA for mailbox/admin accounts
- Review forwarding rules and suspicious inbox filters
- Use a separate admin account where possible
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Email SecuritySPF, DKIM, and DMARC BasicsRead practical stepsClose practical steps
SPF identifies permitted sending servers; DKIM verifies a domain's message signature. DMARC connects a passing SPF or DKIM result to the visible From domain. Authentication does not establish that the content is trustworthy.
Why it matters
Weak or missing authentication can make spoofing, invoice fraud, and questionnaire follow-up harder to manage.
Who should review it
Businesses that send email from a company domain through Microsoft 365, Google Workspace, marketing tools, invoicing systems, or website forms.
What to check
- List every service that sends email for the domain
- Confirm SPF exists and does not include unknown senders
- Enable DKIM for each legitimate sender where available
- Publish DMARC in monitoring mode before enforcing stricter policy
When to ask for help
- You are not sure which services send email for the domain
- DMARC reports show failures you cannot explain
Email SecurityDMARC in Plain EnglishRead practical stepsClose practical steps
DMARC connects the visible From domain to SPF or DKIM authentication. It passes when either method passes with domain alignment; the published policy guides handling when neither does. It does not prove a message is safe.
Why it matters
Weak or missing DMARC can make it easier for criminals to spoof a domain and send fake invoices, vendor messages, or staff impersonation emails.
Who should review it
Businesses using Microsoft 365, Google Workspace, or any service that sends email from the company domain.
What to check
- Confirm SPF exists and includes only legitimate senders
- Enable DKIM for Google Workspace, Microsoft 365, Resend, or other senders
- Publish DMARC and monitor results before moving to stricter enforcement
- Review reports before changing policies to reject
- Consider subdomains and third-party senders before tightening policy
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Website SecurityWebsite & Domain SecurityRead practical stepsClose practical steps
Keep your public website, contact forms, booking links, and trust signals from becoming easy business risk.
Why it matters
Website and domain gaps can create trust issues before a customer, patient, or client ever calls.
Who should review it
Businesses with websites, contact forms, booking pages, payment links, or client intake forms.
What to check
- Confirm HTTPS works on the public website
- Review DNS records and domain renewal ownership
- Check basic security headers and public form handling
- Remove unused plugins, pages, and old admin users
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Website SecuritySecurity Headers ExplainedRead practical stepsClose practical steps
Security headers are browser instructions that help reduce common website risks such as clickjacking, unsafe content loading, MIME sniffing, and overly broad browser permissions.
Why it matters
Headers do not make a site invincible, but missing or weak headers are visible signals that a site may need safer browser-side defaults.
Who should review it
Businesses with public websites, booking pages, client portals, forms, or embedded third-party tools.
What to check
- Confirm HSTS only after HTTPS is stable
- Add CSP carefully and test forms, images, payments, and analytics before tightening
- Use X-Frame-Options or frame-ancestors to reduce unwanted framing
- Review Referrer-Policy and Permissions-Policy so pages share less browser context
When to ask for help
- A scanner reports missing headers and the web host, CDN, and developer disagree about ownership
- A CSP change could break scripts, forms, checkout, booking, or embedded widgets
Website SecurityHTTPS, SSL, and TLS BasicsRead practical stepsClose practical steps
HTTPS encrypts the browser connection and authenticates the website hostname; it does not prove the business or content is trustworthy.
Why it matters
Broken HTTPS, mixed content, or missing redirects can make a legitimate website look unsafe and can confuse customers or providers.
Who should review it
Any business with a public website, contact form, booking flow, payment link, or customer intake path.
What to check
- Confirm the main website loads over HTTPS
- Confirm HTTP redirects to HTTPS
- Check that the certificate matches the right domain
- Ask the host or web provider to fix certificate or redirect warnings
When to ask for help
- Browsers show certificate warnings or redirect loops
- Multiple providers disagree about who owns the fix
FoundationsDNS Exposure and OwnershipRead practical stepsClose practical steps
DNS records route website, email, verification, and vendor services. Owners should know who can change them and why each record exists.
Why it matters
Unclear DNS ownership can delay security fixes, email changes, website launches, and vendor handoffs.
Who should review it
Businesses that inherited a domain, changed vendors, use multiple marketing/email tools, or are not sure where DNS is hosted.
What to check
- Identify the registrar and DNS host
- List major DNS records and what provider each one supports
- Remove stale verification records after confirming they are no longer needed
- Require MFA for accounts that can change DNS
When to ask for help
- Nobody knows who controls DNS or renewal settings
- A vendor asks for DNS changes and the business cannot verify impact
FoundationsWHOIS and Domain InformationRead practical stepsClose practical steps
Public registration records can provide registrar and registration-status clues. They do not establish who can sign in, recover the account, or control auto-renew: confirm those details in the authorized registrar account.
Why it matters
Domain ownership problems can interrupt website and email service, delay DNS changes, and make vendor handoff harder.
Who should review it
Businesses that inherited a domain, switched vendors, missed renewal notices, or are unsure who controls the registrar account.
What to check
- Identify the registrar and account owner
- Confirm renewal status and auto-renew settings
- Use registrar privacy where appropriate, while keeping internal ownership records clear
- Document DNSSEC status and registrar-lock options before changing providers
When to ask for help
- The domain is under an old vendor, employee, or unknown account
- Renewal, privacy, DNSSEC, or registrar-lock status is unclear
FoundationsDNS, VPN, and WebRTC VisibilityRead practical stepsClose practical steps
Browser and network checks can show what websites may see about your current connection, including public IP, IP version, and browser-exposed WebRTC candidates.
Why it matters
These signals do not prove anonymity, but they help users understand whether a network change appears to be visible to websites.
Who should review it
Owners and staff who use VPNs, remote work networks, shared Wi-Fi, hotspots, or browsers with WebRTC enabled.
What to check
- Check your public IP before and after enabling a VPN
- Run the IP, DNS & WebRTC Connection Check to review basic browser and WebRTC signals
- Use your VPN provider's own diagnostic page for resolver-specific validation
- Treat mDNS .local WebRTC results as privacy protection, not a failure
When to ask for help
- VPN behavior differs across browsers or devices and staff need plain-English guidance
- A business needs remote-access cleanup rather than a consumer anonymity test
FoundationsPublic IP, IPv4, IPv6, and CGNATRead practical stepsClose practical steps
A public IP is the IPv4 or IPv6 address a website sees on a request. It may identify an ISP, VPN, proxy or mobile-network exit. With carrier-grade NAT (CGNAT), several customers can share an ISP's public exit address.
Why it matters
Knowing what IP version and network are visible helps owners avoid confusing a normal provider change with a security issue.
Who should review it
Anyone troubleshooting VPNs, remote work, office networks, website allowlists, provider tickets, or suspicious sign-in alerts.
What to check
- Run the IP, DNS & WebRTC Connection Check
- Compare results on office Wi-Fi, mobile hotspot, and VPN
- Ask the ISP or IT provider whether the address is static, dynamic, or behind CGNAT when allowlisting matters
- Check IPv6 behavior separately because some VPNs handle IPv6 differently
When to ask for help
- A vendor asks for IP allowlisting and the business does not know whether the address changes
- IPv6 behaves differently from IPv4 when VPN, firewall, or remote access is enabled
Access ControlAdmin and Login ExposureRead practical stepsClose practical steps
Reduce risk from exposed admin paths, old vendor access, weak MFA coverage, and unclear account ownership.
Why it matters
A small number of overpowered accounts often control the website, email, DNS, payments, forms, and customer communication.
Who should review it
Businesses with website admins, domain/DNS admins, payment tools, cloud accounts, booking systems, former staff, or outside vendors.
What to check
- Require MFA for website, domain, DNS, email, payment, payroll, and cloud administrator accounts
- Remove old staff, contractor, and vendor accounts
- Document who owns each admin account and recovery path
- Avoid sending passwords, recovery codes, API keys, or secrets through forms or email
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Website SecurityOutdated Plugins and Platform RiskRead practical stepsClose practical steps
Review CMS, plugin, theme, form, booking, payment-link, and website platform exposure before small maintenance gaps become cleanup projects.
Why it matters
Outdated website components and unmanaged integrations can create trust, maintenance, and security problems that are harder to fix during a vendor handoff.
Who should review it
Businesses using WordPress, website builders, booking widgets, form plugins, marketing scripts, payment links, or vendor-managed sites.
What to check
- List the CMS, plugins, themes, form tools, booking tools, payment links, and marketing integrations
- Remove unused plugins, abandoned integrations, demo content, and old admin users
- Confirm who updates the platform and who can restore the site
- Use a Snapshot to decide whether cleanup, redesign, takeover, or vendor handoff is the right next step
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Website SecurityForms and Spam ProtectionRead practical stepsClose practical steps
Contact, booking, newsletter, quote, and intake forms should collect only needed information and reduce automated abuse without blocking real customers.
Why it matters
Poor form handling can flood inboxes, expose sensitive requests, or train staff to ignore legitimate messages.
Who should review it
Businesses with public forms, booking widgets, quote forms, newsletters, lead magnets, or customer intake pages.
What to check
- Keep public forms short and avoid sensitive fields
- Use honeypots, rate limits, and neutral success responses for spam
- Do not ask for passwords, private keys, payment cards, or customer records
- Review where form notifications and stored submissions go
When to ask for help
- Form spam is flooding the inbox or hiding real requests
- A form asks for sensitive information it should not collect
Access ControlDomain Registrar Access and MFARead practical stepsClose practical steps
The registrar controls the domain registration and can affect the website, email, DNS, renewal, and ownership recovery path.
Why it matters
A lost or compromised registrar account can interrupt website and email operations or make recovery difficult.
Who should review it
Owners, office managers, web vendors, and IT providers responsible for domain renewal or domain-level changes.
What to check
- Confirm the registrar name and billing owner
- Turn on MFA for registrar administrators
- Remove old vendor or staff access
- Document recovery email, phone, and renewal contact details
When to ask for help
- The domain is registered under an old vendor or employee account
- Renewal, recovery, or ownership details are unclear
FoundationsSecurity Questionnaire & Evidence SupportRead practical stepsClose practical steps
Prepare a supportable Security Questionnaire & Evidence Support Package when a client, customer, partner, or vendor due-diligence team asks about your own security controls. This does not assess your vendors. Insurance applications and renewals use the separate Cyber Insurance Evidence Review.
Why it matters
Unsupported questionnaire answers can create business risk and follow-up work if evidence does not match reality.
Who should review it
Businesses asked by a customer or partner to provide evidence of their own security controls.
What to check
- Identify what the questionnaire is really asking
- Collect evidence for MFA, backups, access, policies, and vendors
- Avoid claiming controls that are not actually in place
- Use plain-English notes for owner or IT provider approval
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Insurance ReadinessCyber Insurance Readiness QuestionsRead practical stepsClose practical steps
Plain-English guidance on common cyber insurance application topics such as MFA, backups, email authentication, admin access, and vendor documentation. This is not legal, insurance, or compliance advice.
Why it matters
Owners need to understand what insurers commonly ask for before claiming controls or submitting unsupported answers.
Who should review it
Small businesses preparing for cyber insurance applications, renewals, broker questions, or insurer follow-up requests.
What to check
- Identify MFA coverage for business email, admin accounts, and key systems
- Confirm backups exist and know who can restore critical files
- Review SPF, DKIM, DMARC, and basic email-security evidence
- Collect vendor-ready notes for IT, web, DNS, email, and software vendors
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
FoundationsSecurity PrioritiesRead practical stepsClose practical steps
A practical starting point for deciding what to review first when everything feels important.
Why it matters
Owners need a short, defensible fix order before spending time or money on deeper security work.
Who should review it
Every small business with email, a website, online payments, client records, or cloud accounts.
What to check
- List the accounts, website, email provider, and files that matter most
- Turn on MFA for owner, email, banking, payroll, and admin accounts
- Confirm backups exist and at least one restore has been tested
- Use a Snapshot when you need a prioritized public-facing review
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Website SecurityWebsite Redesign Security ChecklistRead practical stepsClose practical steps
Security and ownership basics to include when rebuilding an outdated or confusing small-business website.
Why it matters
A redesign is the best time to clean up SSL/TLS, forms, admin access, domain/DNS ownership, and vendor handoff before old issues are rebuilt into the new site.
Who should review it
Businesses replacing a website, changing platforms, adding forms, or hiring a new web vendor.
What to check
- Confirm who controls the domain, DNS, website hosting, and forms
- Review HTTPS, redirects, and security headers before launch
- Document admin accounts and MFA
- Keep launch and owner handoff notes
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
FoundationsDomain and Email Ownership ChecklistRead practical stepsClose practical steps
A plain-English checklist for identifying who controls the domain, DNS, email provider, senders, and account recovery paths.
Why it matters
When ownership is unclear, website, email, and security fixes take longer and can become risky during vendor transitions.
Who should review it
Owners who inherited a website, changed vendors, or are not sure where DNS and email settings live.
What to check
- Identify the domain registrar and DNS provider
- List the website host, email provider, and major senders
- Confirm admin accounts and MFA status
- Document renewal contacts and recovery paths
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
FoundationsVendor Handoff ChecklistRead practical stepsClose practical steps
A checklist for taking over from a web, DNS, email, marketing, or IT provider without guessing who owns what.
Why it matters
A clean handoff reduces lockout risk and makes the next provider conversation more concrete.
Who should review it
Businesses switching vendors, recovering from poor handoff, or cleaning up a messy existing setup.
What to check
- Collect provider names and account owners
- Confirm authorization before requesting or changing access
- Document domains, DNS zones, hosting, forms, email, and admin accounts
- Avoid sending passwords through email or forms
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Cloud AccountsMicrosoft 365 / Google WorkspaceRead practical stepsClose practical steps
Understand account ownership, MFA, recovery, and offboarding in the workspace where your daily work happens. Business Security Baseline is an authorized configuration and evidence review; implementation is scoped separately.
Why it matters
A compromised cloud account can expose client records, invoices, contracts, employee data, and internal files.
Who should review it
Businesses using Microsoft 365, Outlook, Gmail, Google Workspace, SharePoint, OneDrive, or Google Drive.
What to check
- Require MFA for all users
- Review admin users and shared mailboxes
- Disable unused accounts quickly
- Check external sharing settings
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Scam PreventionScams & PhishingRead practical stepsClose practical steps
Build simple habits that help owners and staff slow down suspicious invoices, links, texts, and urgent requests.
Why it matters
Payment-change scams and fake login messages can move quickly if staff do not have a simple verification habit.
Who should review it
Owners, office managers, finance staff, receptionists, and anyone who handles email, invoices, texts, or calls.
What to check
- Verify payment and bank-change requests out of band
- Train staff to pause before opening links or attachments
- Report suspicious messages internally
- Use MFA so stolen passwords are less useful
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
ResilienceBackups & RecoveryRead practical stepsClose practical steps
Make sure important business files can be restored after deletion, device loss, account compromise, or ransomware.
Why it matters
Recovery planning keeps a bad day from becoming a long business interruption.
Who should review it
Businesses that store documents, customer records, invoices, images, contracts, schedules, or operational files.
What to check
- Identify critical files, systems, and cloud accounts
- Use cloud backup, versioning, or another documented backup path
- Test restoring a file before there is an emergency
- Document who to call if systems go down
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Access ControlPasswords, MFA & OffboardingRead practical stepsClose practical steps
Reduce risk from old accounts, shared passwords, overpowered admin access, and unmanaged staff changes.
Why it matters
Old accounts, shared passwords, weak passwords, and unnecessary admin access create easy entry points.
Who should review it
Any business with employees, contractors, vendors, shared accounts, or former staff.
What to check
- Use a password manager
- Avoid shared passwords where possible
- Remove access immediately when someone leaves
- Give admin access only when needed
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
Scam PreventionPersonal Cybersecurity for OwnersRead practical stepsClose practical steps
Protect the owner and key decision-makers whose personal email, phone, and recovery settings often control business access.
Why it matters
Owner account compromise can affect business email, banking, domain access, social media, and customer communication.
Who should review it
Owners, partners, office managers, and family members who control business accounts, payments, devices, or recovery emails.
What to check
- Secure the primary personal email account first
- Turn on MFA for identity, banking, phone, and cloud accounts
- Review recovery emails, phone numbers, and unknown devices
- Do not send passwords, recovery codes, SSNs, or bank details through forms
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
ResilienceExternal Security WatchRead practical stepsClose practical steps
Keep website, domain, email, and public-facing security signals from drifting after a Snapshot, cleanup, rebuild, takeover, or agreed baseline.
Why it matters
Basic security hygiene can drift when domains, email tools, websites, vendors, and staff access change over time.
Who should review it
Small businesses that want scoped monthly website and public-facing security oversight without buying a full MSP, helpdesk, SOC, or MDR.
What to check
- Document the baseline after fixes are complete
- Review public domain, email, and website signals on a cadence
- Track follow-up items, ownership, and vendor-ready notes
- Use External Security Watch for scoped oversight, not 24/7 monitoring
When to ask for help
- You are not sure who owns the setting or provider account
- A client, vendor, insurer, or provider needs clearer evidence
ResilienceIncident and Account Compromise Triage BoundariesRead practical stepsClose practical steps
Owners should know what to do first when an account, email, domain, or website looks suspicious, and when CyberBit's standard services are not emergency incident response.
Why it matters
Clear boundaries prevent delayed emergency action and keep routine cleanup separate from active incident handling.
Who should review it
Businesses seeing suspicious inbox rules, unknown admin users, payment-change messages, website defacement, or provider alerts.
What to check
- Preserve suspicious messages, timestamps, and provider alerts
- Change passwords and revoke sessions only through trusted provider guidance
- Contact the affected provider, bank, insurer, or legal adviser when appropriate
- Use cleanup or Snapshot only after immediate safety and ownership questions are stable
When to ask for help
- Money movement, customer data, or active account compromise may be involved
- You need emergency response beyond public-signal review or cleanup planning
FoundationsSafe Handoff to IT or Web ProvidersRead practical stepsClose practical steps
A safe handoff gives the right provider enough context to fix website, email, DNS, and account issues without passing secrets around casually.
Why it matters
Clean handoff notes reduce lockout risk, duplicated work, and unsupported changes to critical settings.
Who should review it
Businesses switching web vendors, IT providers, marketing agencies, website platforms, or email providers.
What to check
- List current providers and account owners
- Confirm authorization before access changes
- Share vendor-ready notes instead of passwords in email
- Document what changed, who changed it, and what still needs follow-up
When to ask for help
- A provider asks for broad admin access without explaining why
- You need a prioritized fix order before assigning work
Glossary
Plain-English cybersecurity terms owners actually see.
Use these definitions when a provider, insurer, vendor, or questionnaire uses technical language.
DNS
The settings that tell the internet where your website, email, and other domain services live.
Registrar
The company where your domain is registered and renewed. Registrar access should use MFA.
SPF
An email policy identifying permitted sending servers. DMARC also checks alignment with the visible From domain.
DKIM
A domain signature that lets receivers check signed message content. It does not prove the message is safe.
DMARC
A policy tied to the visible From domain. It passes when SPF or DKIM passes with domain alignment; neither passing means DMARC fails.
HTTPS
An encrypted connection to the website, not proof that the website or its content is trustworthy.
SSL/TLS
TLS protects data in transit. Certificates help authenticate the connection; they do not certify a secure application.
Security headers
Browser instructions that reduce common web risks such as framing, sniffing, or unsafe loading.
MFA
Multi-factor authentication. It adds a second proof beyond a password for important accounts.
Admin exposure
Login or administrator areas that are reachable publicly and need intentional protection.
Vendor questionnaire
A client or partner form asking what security controls your business has in place.
Public-signal review
A safe review of what can be checked from outside, without passwords, exploit testing, or private access.
Further reading
Useful resources, close to the source.
Start with a focused CyberBit guide. Use government and standards resources when you need broader context.
Email security basics for small businessesReview SPF, DKIM, DMARC, MFA, and simple habits that reduce spoofing and invoice-fraud risk.Read the guideWhat DMARC means in plain EnglishUnderstand why domain spoofing resistance matters and what owners should ask their email or DNS provider.Read the guideCyber insurance questions owners should prepare forOrganize common control questions without claiming legal, insurance, or compliance advice.Read the guide
Trusted external resources
Independent public guidance. These organizations do not endorse CyberBit.
Free checks / human help
Choose the level of help that matches the decision in front of you.
A free result may answer the initial question. Involve a person when evidence needs interpretation, changes need coordination, or a business deadline needs a defined scope.
Review business accounts and evidence
Business Security Baseline — From $1,250
An authorized review for one Microsoft 365 or Google Workspace tenant, one primary domain, and up to 25 active users. A scorecard, prioritized plan, evidence index, and readout; implementation is separate.
Review Business Security BaselineObserve a specific signal
Free public check
Start with a public-domain or browser-visibility question. Use the result with the responsible provider; human review and implementation are not included.
First human-reviewed PDF draft within 24 hours after payment is confirmed and required intake is complete.
Run free public checkView Sample ReportInterpret and prioritize
Security Snapshot — $199
A human-reviewed explanation of public-facing findings, business impact and the recommended fix order. Review is separate from implementation.
Review Snapshot scopeReview remediation sprintAddress a known issue
Scoped implementation
A defined fix may fit Focused Remediation. Multiple changes or provider coordination may need a Business Security Remediation Sprint. Confirm scope before work starts.
Explore focused cleanupAfter the fixes / ongoing oversight
Keep an eye on the public signals.
External Security Watch is a separate path for ongoing public-signal oversight. It does not replace implementation, internal monitoring or incident response.
Personal Cybersecurity for individuals and families
Personal accounts, family devices and identity concerns need a different conversation from a business website review. Keep private records out of public tools.
Find the personal security pathAuthorized Web Application Penetration Test
For active testing of a customer-controlled custom application within written scope and Rules of Engagement. Separate from public tools. From $4,500.
View penetration test detailsBefore you use a tool
Small-business cybersecurity questions
Is this a penetration test?
No. These tools and resources explain public signals, browser-visible information or your own checklist answers. They do not perform exploit testing, malware scanning, breach detection or a private-system assessment. Authorized application testing is a separate, explicitly scoped service.
What should I never submit in a form?
Do not submit passwords, recovery codes, API keys, private keys, customer records or confidential screenshots. Start with the public domain, the type of issue and non-sensitive business context. Each tool explains its processing and privacy limits.
Does an unknown or missing result mean I have been hacked?
No. A result may reflect an unobserved record, unavailable browser information, a provider limitation or a setting that needs review. Confirm the affected system and evidence with its owner before changing anything.
Can the connection check prove my VPN is working or my DNS is private?
No. It compares what this browser and its requests expose. A changed IP shows a changed observed exit address, not device-wide VPN coverage. It cannot reliably identify your DNS resolver, certify anonymity or give a definitive DNS-leak verdict.
Should I start with a free tool or paid help?
Use a free tool for a specific public-signal or browser-visibility question. Choose Business Security Baseline for authorized workspace configuration and evidence review. Snapshot provides human interpretation of public signals; known fixes can go directly to remediation scope review. Insurance evidence and personal concerns have separate paths.
Can these resources guarantee security or insurance approval?
No. They are general educational guidance, not a certification, compliance opinion, insurance recommendation or guarantee of protection, coverage or approval. Use current evidence and the requirements of the relevant provider or insurer.
Prioritize the work
Want a prioritized review instead of guessing?
Business Security Baseline reviews authorized workspace configuration and evidence. The smaller Snapshot answers public website, email, and domain questions. Already know the issue? Ask about the appropriate remediation scope.
Scope note
CyberBit Solutions LLC provides this center as general educational guidance. It is not incident response, legal advice, compliance certification or a guarantee of security. Tool limits and service scope still apply. Do not submit passwords, recovery codes or private records.