Free Cybersecurity Risk Assessment in Austin & Houston

The strongest discovery questions ask how a control works—and what evidence shows it works. Knowing you have a firewall, antivirus, or Microsoft 365 subscription is a starting point. Understanding who manages it, what it covers, and whether it works helps reveal your business’s actual exposure.

Looking for a free cybersecurity risk assessment in Austin or Houston? Business Communication Solutions (BCS) helps businesses identify security concerns, verify existing safeguards, and prioritize practical next steps. We work with business owners, internal IT teams, and existing providers across Austin, Houston, Lampasas, and surrounding communities.

Request a free cybersecurity assessment: Austin: 512-257-1433 | Houston: 281-815-8784 | Lampasas: 512-865-4000.

Free cybersecurity risk assessment for Austin and Houston businesses

Not sure whether every computer has endpoint protection, remote access requires MFA, or guest Wi-Fi is separated from business systems? Start with a free assessment conversation with BCS. We use risk-discovery questions to understand your environment, discuss available evidence, and identify areas that need closer review. We confirm the assessment scope with you before work begins.

Topics include asset inventory, Microsoft 365, passwords, administrator access, network segmentation, remote work, backups, security monitoring, and vendor access. The questions below help your team prepare—even if another IT provider currently supports your business.

Need SOC 2 or CMMC readiness support? Let us know your customer or contract requirements so we can discuss the appropriate scope. An initial discovery assessment is a starting point; it does not establish compliance or replace a formal audit, certification assessment, penetration test, or comprehensive framework-specific risk analysis.

Cybersecurity risk assessment questions: prepare for your review

Use these questions with your business owner, IT staff, MSP, and department leaders. For every answer, ask who owns the control, how it works, when it was tested, and what evidence verifies it.

How to use these questions

For each topic, record the current answer, responsible person, evidence, last verification date, and any follow-up action. Use “Verified,” “Partially implemented,” “Unknown,” or “Not applicable—with a reason.” An unknown answer is a discovery item, not proof that a breach has occurred. A yes answer without evidence is not the same as a verified control.

Keep the completed answers and supporting records in an approved, access-controlled location. Do not email passwords, recovery keys, sensitive network configurations, CUI, or patient records as questionnaire responses. Share sensitive evidence through an agreed secure process.

Discovery questionnaire, gap assessment, and risk assessment: what is the difference?

This page is a discovery guide. A gap assessment compares current controls against a defined requirement or baseline. A risk assessment also identifies what could go wrong, the threats and weaknesses involved, existing safeguards, the likelihood of the event, and its business impact. Findings then support decisions about treatment, ownership, and follow-up. Completing a questionnaire alone does not establish compliance.

For background, see the NIST Risk Management Framework Small Enterprise Quick Start Guide and HHS guidance on risk analysis.

1. What does your business need to protect?

• Which systems keep payroll, customer service, billing, production, and daily operations running?
• What sensitive information do you hold, where does it live, and who can access it?
• How long could the business operate without email, internet, phones, key applications, or its main server?
• Who owns the inventory of computers, servers, cloud applications, network devices, and critical vendors?

Evidence to review: Asset and application inventories, data-flow records, business-process owners, and documented downtime tolerances.

2. How does each employee authenticate to company computers?

• Does every employee have a unique account, or do people share computer logins?
• Are accounts centrally managed through Active Directory or Microsoft Entra ID, or managed separately on each computer?
• How is MFA enforced for the relevant sign-in scenarios? What exceptions exist?
• What happens to computer, cloud, and remote access when an employee leaves or changes roles?

Evidence to review: Account lists, identity configuration, sign-in records, MFA enforcement tests, and onboarding/offboarding tickets.

3. How does your network identify and authorize devices?

• Can someone plug a personal laptop into an Ethernet jack and reach company systems?
• What determines whether a device is allowed to connect: certificates, network access control, device compliance, an approved exception, or another method?
• Can an approved employee use an unapproved or unhealthy device to reach sensitive resources?
• Who reviews unknown devices and removes obsolete equipment from the inventory?

Evidence to review: Device inventories, enrollment/compliance records, network-access configuration, and authorized tests from approved and unapproved devices.

Separate the person from the device: A valid employee login does not by itself prove that the computer is approved, patched, encrypted, or protected. Network access and access to business applications also need to be evaluated separately.

4. Do employees and guests share the same Wi-Fi password?

• Does each employee authenticate individually, or does everyone use one shared Wi-Fi password?
• Do guests, contractors, employees, and IoT devices use separate access arrangements?
• When a person leaves, can you remove their access individually? If a shared password remains, who changes it and updates authorized devices?
• Can guest or personal devices reach company computers, printers, management interfaces, or sensitive systems?

Evidence to review: Wi-Fi security settings, authentication records, guest isolation rules, authorized-user lists, and connectivity tests.

5. How many VLANs do you have—and what does each one do?

• Can you identify your Main/Business, Server, IoT, Camera, Voice, Management, and Guest networks, where applicable?
• Which devices belong in each VLAN, and who maintains that assignment?
• What firewall or access-control rules allow traffic between those networks?
• Have you tested whether guests and IoT devices are actually blocked from sensitive business resources?

Evidence to review: A current network diagram, VLAN/subnet inventory, firewall rules, and approved segmentation-test results.

The number of VLANs is not a security score. A VLAN label alone does not establish isolation; permitted traffic, management access, routing, and enforcement determine the separation.

6. Do you use SSL VPN or another remote-access method?

• Do users access office resources through SSL/TLS VPN, IPsec VPN, a zero-trust access service, remote desktop, or another tool?
• Does each remote user have a named account, suitable MFA, and only the access needed?
• Are remote-access appliances and clients supported, patched, and monitored? Is remote desktop exposed directly to the internet?
• Can personal devices connect, and can unused accounts or active sessions be revoked promptly?

Evidence to review: Remote-access inventory, configuration and patch records, MFA tests, access rules, and connection logs.

7. Do you use Microsoft 365—and which licenses do you have?

• Which Microsoft 365 or Office 365 license is assigned to each user, including field staff and administrators?
• Which security capabilities are licensed, configured, enforced, and monitored—and who verifies the difference?
• Who reviews MFA, privileged roles, sign-in risk, external sharing, mailbox forwarding, and application permissions?
• How are company devices and data managed, including personal devices and employee departures?

Evidence to review: License assignments, tenant security settings, access policies, device-management reports, and documented administrator reviews.

A purchased license does not prove that every included control is enabled or that all users are covered. Where device management is relevant, learn about Microsoft Intune setup and support.

8. Do you have endpoint protection, EDR, MDR, SIEM, or SOAR?

• What products and services are deployed, and what job is each expected to perform?
• Are all relevant computers, servers, identities, cloud services, and network devices covered?
• Who investigates alerts during business hours, overnight, on weekends, and on holidays?
• Who can isolate a device or disable an account, and what requires customer approval?
• When did you last verify agent health, log ingestion, alert delivery, and the response process?

Evidence to review: Coverage reports, agent status, log-source lists, service agreements, alert tickets, response authorizations, and controlled test results.

Endpoint protection helps prevent malicious activity; EDR adds endpoint detection and response capabilities. MDR provides a managed detection-and-response service. SIEM collects and analyzes security events, while SOAR supports automated workflows. Product names alone do not establish coverage, response, or a requirement to purchase every category.

9. Do employees have local administrator access?

• Can employees install software, change security settings, or disable protection on their computers?
• Are privileged accounts separate from everyday accounts?
• Are local administrator credentials unique per device and centrally controlled?
• Can temporary elevation be approved, limited, and recorded instead of granting permanent administrator rights?

Evidence to review: Local administrator membership reports, elevation settings, credential-management configuration, and privilege-use records.

10. Do employees work from home or use public Wi-Fi?

• Do employees use company-managed devices, personal computers, or both?
• Do they connect through coffee shop, airport, hotel, or other public Wi-Fi?
• What approved secure-access methods and endpoint protections apply away from the office?
• Can business files be downloaded, printed, synchronized, or copied to unmanaged devices?
• How are lost devices, suspicious sign-ins, and unapproved remote-access software reported?

Evidence to review: Remote-work/BYOD policies, device compliance reports, access restrictions, secure-access settings, and incident-reporting procedures.

Public Wi-Fi use is a risk to evaluate, not automatic evidence of compromise. Verify the network, use approved secure access, and protect the device itself. A VPN does not prevent phishing or make a compromised computer safe. See CISA’s mobile workplace security guidance.

11. Are laptops and desktops encrypted?

• Is full-disk encryption, such as BitLocker or FileVault, enabled on relevant laptops and desktops?
• Can IT verify encryption status centrally rather than relying on an employee’s answer?
• Where are recovery keys stored, who can retrieve them, and has recovery been tested?
• What happens if a device is lost, stolen, retired, or reassigned?

Evidence to review: Encryption-compliance reports, controlled recovery-key records, recovery tests, and device-retirement procedures.

Disk encryption helps protect data on a lost or stolen device. It does not stop an attacker who gains access to an unlocked session or an authorized account.

12. Can your MSP oversee your company password manager?

• Where are business credentials stored: an approved company vault, browser profile, spreadsheet, email, or personal account?
• Does each employee and MSP technician have an individual vault account with appropriate authentication?
• What can the MSP administer, view, export, transfer, or recover—and who approves that access?
• Are necessary shared credentials controlled, and can system actions be linked to individual users?
• Who responds to compromised-password alerts, removes departing users, and maintains customer emergency access?
• Are personal passwords kept in separate personal accounts?

Evidence to review: Vault policies, permissions, audit records, recovery tests, alert-remediation tickets, and the customer/MSP responsibility agreement.

Read our business password manager guide for sharing, MSP oversight, built-in browser options, and compliance considerations.

Watch: BCS Business Password Managers on YouTube.

13. Can you recover—and who responds when something goes wrong?

• What is backed up, how often, and where are protected copies stored?
• Are backup administration and deletion protected from ordinary user accounts and a compromised production environment?
• When was the last successful restore test, and did it meet the business’s recovery needs?
• Who calls the MSP, insurer, legal counsel, and other response contacts during an incident?
• Have employees practiced reporting phishing, suspicious activity, and lost devices?

Evidence to review: Backup coverage, restore-test results, recovery objectives, incident contacts, and exercise records.

Use tabletop exercises and incident-response practice to test decisions and responsibilities before a real event.

14. Which compliance obligations actually apply?

• Do customer contracts, government contracts, regulators, or insurers impose security requirements?
• Are you pursuing SOC 2 Type I or Type II, CMMC Level 1 or Level 2, HIPAA compliance, ISO/IEC 27001 certification, or PCI DSS obligations?
• Do you handle Federal Contract Information (FCI), Controlled Unclassified Information (CUI), electronic protected health information (ePHI), or payment card data?
• Which systems, users, locations, vendors, and data flows are in scope?
• Who owns the applicable requirements, evidence, assessment schedule, and remediation plan?

Evidence to review: Contracts, data classifications, scope records, applicable requirements, responsibility assignments, and prior assessment findings.

Different obligations have different scopes and evidence requirements. This questionnaire does not establish compliance or replace a framework-specific assessment. BCS provides SOC 2 readiness and gap assessment support and CMMC consulting and implementation support.

15. Is your asset inventory complete and accurate?

• Do you have an inventory of all company assets, including laptops, desktops, servers, virtual machines, firewalls, switches, wireless access points, cameras, IoT devices, and cloud services?
• Does each asset record identify its owner, business purpose, location, support status, and the information it can access?
• How do you reconcile the inventory against network discovery, identity records, purchasing records, cloud consoles, and device-management tools?
• How do you discover equipment that is offline, rarely connected, newly purchased, personally owned, or installed without IT approval?
• When was the inventory last validated, who checked it, and how were discrepancies resolved?
• When assets are retired, are access rights, licenses, stored data, and inventory records updated?

Evidence to review: A dated inventory, discovery and reconciliation reports, discrepancy tickets, ownership records, and retirement records.

16. How do you know whether an endpoint is missing security coverage?

• What independent inventory defines the full population of endpoints that should be protected?
• Do you compare that population against EDR, device management, patch management, disk encryption, and other required security-tool reports?
• Can you distinguish an installed agent from one that is healthy, licensed, correctly configured, assigned the right policy, and reporting recently?
• Does your MDR provider monitor every intended endpoint, tenant, or log source, and how is that scope confirmed?
• Who investigates missing agents, stale check-ins, disabled protection, excluded devices, and newly provisioned machines?
• Are authorized exceptions recorded with an owner, reason, safeguards, and review date?

Evidence to review: A coverage matrix matching assets to required controls, agent-health reports, MDR scope records, last-seen timestamps, exception records, and remediation tickets.

A console cannot prove coverage of devices it does not know about. Compare security reports against an independently validated inventory. MDR is a service whose scope must be confirmed; an installed endpoint agent alone does not demonstrate that the intended managed monitoring and response are active.

17. Who checks the critical work of administrators?

• Which administrative changes require a second qualified person to review or approve them?
• If several administrators manage the same environment, how are changes coordinated, documented, and assigned to an owner?
• Can one administrator grant themselves access, change security controls, and alter the records used to review their own work?
• Who reviews changes to firewall rules, privileged roles, MFA exclusions, backup retention, email forwarding, and security-tool exclusions?
• If you have only one administrator, can another qualified person or an external provider perform an appropriate independent review?
• How are urgent changes handled, and who reviews them afterward?

Evidence to review: Change tickets, reviewer approvals, role-separation records, privileged-activity logs, and post-change reviews.

18. How do you detect configuration mistakes and drift?

• Do you have approved configuration baselines for critical systems, and how are exceptions documented?
• After a change, do you test both the intended result and whether prohibited access remains blocked?
• Do you use configuration reviews, vulnerability scans, or posture assessments appropriate to the environment?
• Can you detect when settings drift from the approved baseline or a security control is turned off?
• Are significant changes backed up with a tested rollback or recovery procedure?
• Who verifies remediation with a retest rather than closing a ticket based only on someone reporting it fixed?

Evidence to review: Baseline records, configuration comparisons, authorized test results, scan findings, rollback plans, and remediation retests.

For example, after changing a guest-network firewall rule, verify that guests can reach the internet and cannot reach protected business resources. A successful internet connection alone does not demonstrate that isolation works.

19. How often do you run tabletop exercises—and what changes afterward?

• When was your last tabletop exercise, and when is the next one scheduled?
• What determines the schedule: business risk, contracts, applicable requirements, incidents, or significant changes?
• Do exercises include leadership, IT/MSP staff, operations, HR, finance, and other relevant decision-makers?
• Have you practiced ransomware, business email compromise, lost devices, vendor outages, and loss of access to critical accounts?
• Does the scenario test after-hours contacts, decision authority, communication, recovery priorities, and notification responsibilities?
• Are lessons assigned to owners with due dates, and do you retest unresolved issues?

Evidence to review: Exercise schedules, scenarios, attendance, decision records, after-action reports, and tracked improvements.

A tabletop exercise tests decisions and coordination. Pair it with appropriate technical tests—such as restoring a backup or validating an alert—rather than assuming a discussion proves those controls operate. Explore BCS tabletop exercises and incident-response practice.

20. How often are policies reviewed, updated, and put into practice?

• Does every security policy have an owner, approver, version, last-review date, and next-review date?
• Does the review schedule reflect applicable requirements and the business’s risks?
• Are policies revisited after incidents, major technology changes, new data types, new vendors, or changes in remote work?
• Do policies describe what employees and administrators actually do, including BYOD, passwords, remote access, and exceptions?
• When a policy changes, who updates technical settings, procedures, training, and employee acknowledgments?
• How do you confirm employees can find and understand the current version, and that obsolete versions are withdrawn?

Evidence to review: A policy register, review history, approvals, linked procedures and settings, training records, and exception tracking.

A review can conclude that no change is needed; document that decision and its basis. An updated policy document alone does not demonstrate that the required settings or operating practices changed.

21. How do you find and fix vulnerabilities?

• Which operating systems, applications, browser extensions, network devices, and internet-facing services are included in patch management?
• Who tracks unsupported products, security advisories, and newly disclosed vulnerabilities?
• How do you prioritize fixes based on exposure, exploitability, business impact, and applicable deadlines?
• Are failed updates, deferred restarts, and unreachable devices tracked until resolved?
• If a patch cannot be applied, who approves and verifies temporary safeguards?
• Do you rescan or otherwise validate that the vulnerable condition has been addressed?

Evidence to review: Patch-compliance reports, vulnerability findings, exception approvals, support-life records, and verification results.

22. Could a fraudulent email cause a payment or data loss?

• How are requests to change vendor bank details, send urgent payments, or release sensitive records verified through a trusted independent channel?
• Can the same person request, approve, and execute a high-risk payment without another review?
• Who reviews suspicious mailbox forwarding rules, application consent, and unusual sign-ins?
• Can employees quickly report suspicious messages, and who responds?
• Are staff trained to challenge impersonation through email, phone, text, or synthetic audio/video?
• Have you tested the reporting and verification procedures with a realistic, authorized exercise?

Evidence to review: Payment-verification procedures, approvals, email security reviews, reporting tickets, and exercise outcomes.

23. Who can access your business through vendors and cloud applications?

• Which vendors, MSPs, software integrations, and remote-support tools have access to company systems or data?
• Is that access named, limited, approved, and removed when the work or relationship ends?
• Who reviews third-party application permissions, service accounts, API keys, and integration secrets?
• Can you identify the business owner for each application and confirm where company data is stored or shared?
• What responsibilities do vendor contracts assign for monitoring, incident notification, recovery, and account transitions?
• If a critical vendor fails or is compromised, what is your fallback and how would you revoke its access?

Evidence to review: Vendor and application inventories, permission reviews, agreements, access logs, secret-management records, and transition plans.

24. Can someone gain access physically or through discarded equipment?

• Are network closets, servers, backup equipment, and management interfaces accessible only to authorized people?
• Can visitors or contractors reach unattended computers, active network jacks, or sensitive printed records?
• Do workstations lock when unattended, including in shared workspaces and at home?
• How are lost badges, keys, devices, and removable media reported and handled?
• Is data securely removed or media destroyed before equipment is sold, recycled, returned, or reassigned?

Evidence to review: Physical-access reviews, visitor procedures, workstation settings, incident records, and sanitization or destruction records.

25. How do you onboard vendors before giving them access?

• Who requests the vendor, who owns the relationship, and who approves security, privacy, procurement, and contractual requirements?
• What service will the vendor provide, what data will it handle, and what physical, remote, administrative, or integration access does it need?
• Do you assess the vendor before signing the agreement, sending sensitive data, or provisioning access?
• What evidence supports its security claims—for example, a relevant assurance report, certificate scope, security questionnaire, test summary, and remediation status?
• Have you reviewed important subcontractors, data locations, retention, deletion, and incident-notification arrangements?
• Are named accounts, MFA, least privilege, logging, access expiry, and approved support methods established before work begins?
• Who approves outstanding risks or exceptions, and which unresolved issues prevent onboarding?
• Is the vendor entered in an inventory with its owner, ratings, review date, renewal date, and exit plan?

Evidence to review: Vendor intake records, due-diligence findings, report scope and exceptions, signed agreements, access approvals, and completed onboarding checklists.

26. How do you onboard customers without introducing avoidable risk?

• Have you verified the customer’s identity and the authority of the person approving work, access, purchases, and sensitive changes?
• Are the service scope, customer systems, data types, locations, and applicable contractual or regulatory obligations documented?
• What is the initial state of asset inventory, administrator access, backups, endpoint protection, patching, and known security issues?
• Is there an authorized handover from the previous provider, with secure transfer of credentials and removal of obsolete access?
• Are customer environments, credentials, support records, and technician permissions separated appropriately from those of other customers?
• Who is responsible for alerts, after-hours response, remediation, incident notification, recovery, and exceptions?
• What minimum security conditions must be met before remote access or managed services begin, and what happens if the customer declines a necessary safeguard?
• Have you tested required access, monitoring, backups, recovery, and escalation contacts before accepting the onboarding as complete?

Evidence to review: Verified authorized contacts, service agreements, initial assessment findings, responsibility matrices, handover records, accepted-risk records, and onboarding test results.

For an MSP, a signed agreement is only one part of onboarding. Document existing weaknesses and responsibility for remediation; do not treat a customer’s risk acknowledgment as a substitute for meeting mandatory requirements.

27. Which vendors are critical, high risk, medium risk, or low risk?

Record business criticality and security risk separately. Criticality asks how severely the business would be affected if the service failed or could not be replaced. Security risk considers the vendor’s access, data sensitivity, exposure, safeguards, and the likelihood and impact of a security event. One vendor may be both critical and high risk.

Classification	Questions to ask	Illustrative examples
Critical business dependency	Would an outage stop a vital process? How long can we tolerate it? Is there a workable alternative or exit path?	Primary internet or identity service, production platform, backup/recovery provider, or payroll service near a payroll deadline—depending on the business.
High security risk	Can the vendor administer systems, access large amounts of sensitive data, move money, or create exposure across customers?	MSP/RMM provider with broad privileges, payroll processor, sensitive-data hosting service, or a privileged software integration.
Medium security risk	Is access limited but still capable of exposing nonpublic data or disrupting a meaningful business process?	A limited-access SaaS application handling routine nonpublic business information, subject to its actual permissions and safeguards.
Low security risk	Is there little sensitive information, no meaningful system access, and limited impact if the vendor is compromised?	A supplier receiving only public specifications and ordinary purchasing details, with no access to company systems.

These are examples, not automatic ratings. An office supplier given administrator access is no longer low risk simply because it sells office supplies. A widely trusted provider is not automatically low risk, and a SOC 2 report does not remove the need to review the relevant service, scope, exceptions, and customer responsibilities.

• What written criteria determine each rating, and who approves or challenges the result?
• Do you record inherent risk before considering safeguards and residual risk after evaluating them?
• Do critical or high-risk relationships receive deeper due diligence, stronger contractual/access controls, and more frequent review appropriate to the exposure?
• What events trigger reassessment—an incident, expanded access, new data, ownership change, major subcontractor change, or service deterioration?
• Can you remove access, recover or transfer data, and maintain essential operations when the relationship ends?

Evidence to review: Vendor rating methodology, assessed access/data flows, critical-dependency analysis, due-diligence results, residual-risk approvals, reassessment records, and exit tests.

For further guidance, see NIST’s supplier due-diligence quick-start guide and the FTC’s service-provider security guidance. The example ratings here are a practical discussion aid, not a universal classification required by every framework.

Questions that reveal whether follow-through is working

• Who is accountable for this control, and who independently verifies the result?
• What systems or users are missing from the report we are reviewing?
• When was this last tested, and what failed?
• What changed since the last review?
• What evidence would show us that the control stopped working?
• Which findings are overdue, who owns them, and what business exposure remains?
• If the responsible administrator is unavailable tonight, who can act?

Turn discovery answers into a risk register

Describe a realistic event rather than recording only a missing product. Identify the affected business process, the threat and weakness, existing safeguards and their effectiveness, likelihood, and impact. Assign a risk owner, response, target date, and follow-up evidence. Use a consistent rating method; avoid assigning a reassuring score simply because many questions received a yes.

Discovery finding	Potential business risk	Follow-up
Former employees may know a shared Wi-Fi credential.	Unauthorized connectivity could expose reachable company resources.	Verify reachability, remove access, and evaluate individual authentication and segmentation.
Several technicians share one administrator login.	Changes or misuse may be difficult to attribute to an individual.	Evaluate named accounts or controlled privileged access with suitable action/session records.
A laptop’s encryption status is unknown.	A lost device could expose locally stored sensitive information.	Verify actual encryption and recovery-key protection; assess the data and any exposure.
Backup jobs report success, but restores are untested.	A disruption may last longer than the business can tolerate.	Perform an authorized restore test against defined recovery needs.

These examples are starting points, not preassigned risk ratings. The same finding can have different consequences depending on the data, network reachability, existing controls, and business dependence. Document the initial risk, chosen treatment, and remaining risk after controls are verified. Management should review risk acceptance; acceptance does not waive a mandatory obligation.

When should you revisit the answers?

Set a review schedule based on your business and applicable requirements. Also revisit findings after significant network or cloud changes, acquisitions, new vendors, new sensitive data, security incidents, or changes in remote work. Confirm that completed fixes continue to operate.

Start with the questions you cannot confidently answer

You do not need to know every technical answer before asking for help. BCS can work with business owners, internal IT teams, or existing providers to review evidence, identify gaps, and prioritize improvements based on business impact.

For every control, ask: Who owns it? How does it work? What evidence verifies it? What happens if it fails?

Explore our cybersecurity services and managed IT and cybersecurity support, or request a free cybersecurity assessment.

Call BCS: Austin: 512-257-1433 | Houston: 281-815-8784 | Lampasas: 512-865-4000.