oqitor

Enterprise Security Assessment: A Comprehensive Checklist

A detailed checklist for evaluating your organization’s security posture across all critical domains.

  • Security
  • By the Oqitor team
  • Published
  • Updated
  • 8 min read

An enterprise security assessment compares the controls you have in place against a defined standard, rates the gaps by risk, and produces a prioritized plan to close them. A useful assessment is scoped, evidence-based and repeatable. This guide explains how to run one, then gives a checklist across the domains that matter, so a buyer can use it to review their own environment and an advisor can use it to structure a conversation with a client.

Decide what kind of assessment you need

People use the word assessment for several different activities. Pick the one that fits your question.

TypeWhat it doesBest forLimit
Self-assessmentYour team scores itself against a control listA first baseline and regular check-insProne to optimism and blind spots
Vulnerability scanAutomated tools find known weaknesses in systemsRoutine patch and configuration hygieneDoes not show whether weaknesses can be chained into an attack
Penetration testSkilled testers attempt to break in under agreed rulesProving real exposure of specific systemsCovers a defined scope at one point in time
Independent auditA third party tests controls against a formal standardCustomer, insurer or regulatory assuranceMeasures compliance with the standard, not total security

Most organizations need a self-assessment first, then scans and tests on a schedule, and an audit when a customer or regulator asks for one.

How to run the assessment

  1. Set the scope. List the business units, locations, systems, cloud accounts and data types you are covering, and state what is out of scope.
  2. Choose a framework. Do not invent a control list. ISO/IEC 27001, the NIST Cybersecurity Framework and the SOC 2 criteria are widely recognized. The Canadian Centre for Cyber Security also publishes baseline controls aimed at small and medium organizations. Whichever you choose, use it consistently so results can be compared over time.
  3. Gather evidence. For each control, collect proof such as configuration screenshots, policy documents, access lists and test records. A control that exists only in someone’s memory is not in place.
  4. Score each control. Use a simple scale that everyone applies the same way.
  5. Rate the risk. For each gap, consider how likely it is to be exploited and how much damage would follow. Combine the two into a rating of high, medium or low.
  6. Write the plan. Assign every high and medium finding an owner, a fix and a date, then track it to closure.
  7. Repeat. Reassess on a schedule and after major changes such as an acquisition, a cloud move or a new core system.

A simple scoring scale

ScoreMeaning
0, Not in placeThe control does not exist
1, PartialExists in some places, or is informal and undocumented
2, ImplementedDocumented, applied consistently, and owned
3, VerifiedImplemented and tested or independently confirmed to work

The checklist

Work through each domain. Mark an item as met only if you can show evidence for it.

Governance and risk

  • A named executive owns information security, and responsibilities are written down.
  • Security policies exist, are approved, and have been reviewed within the past year.
  • A risk register lists the main risks, their owners and the planned treatment.
  • An inventory of systems, data and suppliers is maintained.
  • Staff complete security awareness training on joining and at least annually.

Identity and access management

  • Multi-factor authentication protects all remote access, email, administrator accounts and cloud services.
  • Single sign-on is used for business applications where supported.
  • Privileged accounts are separate from daily accounts, are limited in number, and are reviewed regularly.
  • Joiners, movers and leavers are handled through a defined process, and leavers lose access promptly.
  • Shared and service accounts are inventoried and have named owners.
  • Access reviews take place on a schedule and are documented.

Network security

  • Firewalls are configured to deny by default, and rules are reviewed periodically.
  • The network is segmented, so a compromised workstation cannot reach servers or sensitive systems directly.
  • Remote access runs through a secured method with multi-factor authentication.
  • Guest and device networks are separated from corporate systems.
  • Wireless networks use strong encryption and enterprise authentication, not a shared password.
  • DNS filtering or an equivalent control blocks known malicious sites.
  • Network logs are collected and retained.

Endpoints and mobile devices

  • Every managed endpoint runs endpoint detection and response or an equivalent protection that is monitored.
  • Operating systems and applications are patched on a defined schedule, and critical fixes have a shorter deadline.
  • Disk encryption is enabled on laptops and mobile devices.
  • Mobile devices that reach company data are enrolled in management. The mobile device management guide covers this in more detail.
  • Local administrator rights are removed from standard users.
  • Unsupported software and operating systems are identified and have a retirement plan.

Email and web

  • Email filtering blocks spam, malicious attachments and impersonation.
  • SPF, DKIM and DMARC are configured for your domains.
  • Staff have a simple way to report suspicious messages.
  • Phishing simulations or exercises run periodically.

Data protection

  • Data is classified, and sensitive data is located and mapped.
  • Encryption is applied to data at rest and in transit.
  • Access to sensitive data is limited by role.
  • Backups follow a documented schedule, are kept separate from production, are protected against tampering, and have been restore-tested.
  • Retention and secure disposal rules exist for data and for retired equipment.

Vulnerability and patch management

  • Systems exposed to the internet are scanned regularly.
  • Findings are rated, assigned and tracked to closure with deadlines.
  • A penetration test has covered the most important internet-facing systems within a defined interval.

Logging, monitoring and incident response

  • Logs from identity, endpoints, network devices and cloud services reach a central place.
  • Someone reviews alerts around the clock or within a stated response time, whether in-house or through a provider.
  • A written incident response plan names roles, decision makers, communication steps and legal contacts.
  • The plan has been exercised in a tabletop or simulation within the past year.
  • A breach notification process exists. Organizations subject to PIPEDA must report breaches of security safeguards that create a real risk of significant harm to the Privacy Commissioner and to affected individuals, and provincial laws such as Quebec’s add their own requirements.

Business continuity and recovery

  • Recovery time and recovery point objectives are defined for critical systems.
  • A recovery plan exists, and a recovery test has been performed.
  • Critical connectivity has a second path, and the resilience claims in the provider’s service agreement have been read. The guide to SLAs explains what to look for.

Third parties and cloud

  • Suppliers with access to your data or systems are inventoried and rated by risk.
  • Contracts include security and breach notification obligations.
  • Cloud accounts follow a security baseline. The cloud security checklist provides one.

Physical security

  • Network equipment, server rooms and wiring closets are locked, and access is logged.
  • Visitors are signed in and escorted.
  • Equipment is wiped or destroyed securely when retired.

Turn findings into a plan

A long list of gaps is not a plan. Sort findings by risk, then by effort, and tackle the high-risk items that are quick to fix first. Typical early wins include multi-factor authentication everywhere, patching internet-facing systems, tested backups and removing standing administrator rights. Group the larger items, such as segmentation or a monitoring service, into projects with owners and budgets. Report progress to leadership in terms of risk reduced, not only controls completed.

Common mistakes

  • Scoring controls without evidence, which produces a flattering and useless result.
  • Scoping so narrowly that the riskiest systems are left out.
  • Treating a vulnerability scan as a full assessment.
  • Producing a report that nobody owns, with no dates and no follow-up.
  • Assessing once and never again.
  • Ignoring suppliers and cloud services, where much of the data now lives.
  • Assuming compliance with a standard means the organization is secure.

Questions to ask a provider

If an outside firm will conduct or support the assessment, ask:

  • Which framework will you assess against, and why is it appropriate for us?
  • Who performs the work, and what are their qualifications and experience?
  • What is in scope and what is excluded, and how will testing avoid disrupting production?
  • What will the report contain, and will findings be rated and prioritized with recommended fixes?
  • How do you protect the sensitive information you will see during the work?
  • Do you offer a retest to confirm fixes, and is it included?

Frequently asked questions

How often should we run a security assessment?

Run a full assessment at least once a year, and run a focused one after a major change such as a merger, a new cloud platform or a significant incident. Automated scanning should run continuously or on a short schedule between assessments.

What is the difference between an assessment and an audit?

An assessment helps you understand your own risk and decide what to fix. An audit is a formal examination by an independent party against a specific standard, and it produces an opinion that others can rely on.

Can we do this ourselves?

You can complete a useful first self-assessment in-house, particularly with a recognized framework. An independent view is valuable for penetration testing and for assurance that others will trust, because people rarely find their own blind spots.

Which standard should we use?

Use the one your customers, insurers or regulators already recognize. If no one is asking, a widely used framework such as ISO/IEC 27001 or the NIST Cybersecurity Framework is a sound starting point.

Your clients ask about this. Sell it to them through Oqitor.

Buying for your own business? Oqitor works through partners. Tell us what you need.