Page 1 of 4

ISO 27001 Self-Assessment: Technological Controls Checklist🛡️

A practical self-assessment for security and compliance leaders working with sensitive or regulated data—built around the ISO 27001 Annex A.8 control set.

ISO 27001 isn’t just a checkbox; it’s a blueprint for proving your organization takes security seriously. But implementation can feel overwhelming, especially when it comes to the detailed technological controls outlined in Annex A.8.

We developed this self-assessment to provide technical and compliance leaders with a clear and practical way to evaluate their current security posture against A.8’s most critical requirements, including secure configurations, access control, vulnerability management, logging, data protection, and more.

Whether you're preparing for ISO 27001 certification, improving internal controls, or getting ready for a client audit, this quiz will help you:

🔍 Identify gaps: in endpoint, network, and infrastructure security

🧪 Spot weaknesses: in your software development lifecycle

🔐 Strengthen policies: around access, monitoring, and data handling

📊 Benchmark your readiness: for compliance and third-party assessments

This is the same control set we use when assessing biotech and digital health platforms—now made practical and easy to use.

⚠️ Note: Some sections of the checklist are iterative (such as Secure-by-Design and Risk Management), meaning they evolve as your product matures. Others (like your Technical File, IFU, and Maintenance Records) are living documents that must be continuously reviewed and updated to remain compliant.

🔧 TECHNOLOGICAL CONTROLS SELF-ASSESSMENT

8.1 – User Endpoint Devices: Are company and personal devices (BYOD) securely configured, monitored, and managed to prevent data leakage or unauthorized access?

Example: All laptops and mobile devices are enrolled in MDM with full disk encryption, remote wipe, and public Wi-Fi restrictions.

8.1 – User Endpoint Devices: Are company and personal devices (BYOD) securely configured, monitored, and managed to prevent data leakage or unauthorized access?

✅ Yes – Technical controls and policies in place and enforced across all endpoints

⚠️ Partially – Basic protections or only on company-owned devices

❌ No – Devices lack central oversight or configuration

8.2 – Privileged Access Rights: Are privileged (admin/root) accounts managed with approval, logging, and time-based controls?

Example: Sysadmin access requires ticketed approval, session monitoring, and is revoked after task completion.

8.2 – Privileged Access Rights: Are privileged (admin/root) accounts managed with approval, logging, and time-based controls?

✅ Yes – Privileged access is tightly managed and reviewed

⚠️ Partially – Admin access exists without full oversight

❌ No – Overuse or shared privileged accounts

8.3 – Information Access Restriction: Is access to sensitive data (e.g., clinical trial results, diagnostic records, genomics, IP) limited by roles and reviewed regularly?

Example: Clinical and research teams only access the data relevant to their trials or therapeutic focus; access rights are reviewed quarterly.

8.3 – Information Access Restriction: Is access to sensitive data (e.g., clinical trial results, diagnostic records, genomics, IP) limited by roles and reviewed regularly?

✅ Yes – RBAC is enforced with clear roles and periodic reviews

⚠️ Partially – Access managed manually or inconsistently

❌ No – Broad access without control

8.4 – Access to Source Code: Is access to internal software, scripts, and automation tools protected and logged?

Example: GitHub enterprise with enforced MFA, audit logs, and team-based access scopes.

8.4 – Access to Source Code: Is access to internal software, scripts, and automation tools protected and logged?

✅ Yes – Access is role-based and audited

⚠️ Partially – MFA or password policy lacks coverage

❌ No – Developers share unrestricted access⚠️ Partially – MFA or password policy lacks coverage

8.5 – Secure Authentication: Do systems enforce MFA and secure password policies for all users, including external collaborators?

Example: MFA is required for LIMS, VPN, and all SaaS accounts; passwords follow NIST SP 800-63.

8.5 – Secure Authentication: Do systems enforce MFA and secure password policies for all users, including external collaborators?

✅ Yes – Secure auth standards applied org-wide

⚠️ Partially – MFA or password policy lacks coverage

❌ No – Weak or shared credentials used

8.6 – Capacity Management: Are infrastructure and system workloads (e.g., for data analysis, diagnostics, or bioinformatics) monitored and forecasted?

Example: High-performance compute platforms used for sequencing and medical AI are monitored to avoid disruptions in diagnostics or research.

8.6 – Capacity Management: Are infrastructure and system workloads (e.g., for data analysis, diagnostics, or bioinformatics) monitored and forecasted?

✅ Yes – Forecasting and monitoring are proactive

⚠️ Partially – Basic monitoring, no forecasting

❌ No – No visibility into capacity

8.7 – Protection Against Malware: Are anti-malware and EDR solutions deployed, centrally managed, and effective across endpoints, servers, and lab/clinical systems?

Example: Real-time protection is active on lab instruments, diagnostic devices, and workstations across departments.

8.7 – Protection Against Malware: Are anti-malware and EDR solutions deployed, centrally managed, and effective across endpoints, servers, and lab/clinical systems?

✅ Yes – Malware controls updated and enforced organization-wide

⚠️ Partially – Coverage is inconsistent

❌ No – No reliable malware protection

8.8 – Management of Technical Vulnerabilities: Is there a regular process for vulnerability scanning, patching, and risk-based remediation?

Example: Nessus scans bi-weekly with prioritized patching; CVEs tracked in a ticketing system.

8.8 – Management of Technical Vulnerabilities: Is there a regular process for vulnerability scanning, patching, and risk-based remediation?

✅ Yes – Policy-driven patch management and risk handling

⚠️ Partially – Inconsistent scanning or patch delays

❌ No – No structured process for vulnerabilities

8.9 – Configuration Management: Are secure configurations defined and enforced for all environments (e.g., cloud platforms, lab systems, diagnostic devices, IoT tools)?

Example: Secure baseline images are used for deploying cloud pipelines, lab servers, and healthcare devices, with audit checks enabled.

8.9 – Configuration Management: Are secure configurations defined and enforced for all environments (e.g., cloud platforms, lab systems, diagnostic devices, IoT tools)?

✅ Yes – Secure baselines are defined, monitored, and reviewed

⚠️ Partially – Some configurations enforced manually

❌ No – No baseline configurations

8.10 – Information Deletion: Is secure deletion or data sanitization performed for systems handling regulated data like PII, PHI, genomic data, or IP?

Example: De-identified patient records or outdated clinical trial datasets are securely deleted with traceable audit logs.

8.10 – Information Deletion: Is secure deletion or data sanitization performed for systems handling regulated data like PII, PHI, genomic data, or IP?

✅ Yes – Procedures for secure deletion exist and are verified

⚠️ Partially – Manual deletion with no verification

❌ No – No defined deletion process

8.11 – Data Masking: Is sensitive data (e.g., patient, genomic) masked when used in test/dev environments?

Example: Development environments use synthetic datasets generated by data masking tools.

8.11 – Data Masking: Is sensitive data (e.g., patient, genomic) masked when used in test/dev environments?

✅ Yes – Masking is automated and policy-enforced

⚠️ Partially – Ad hoc masking in some environments

❌ No – Real data used inappropriately

8.12 – Data Leakage Prevention: Are technical controls in place to prevent unauthorized transfer or disclosure of sensitive data?

Example: DLP tools monitor and block uploads of unmasked patient records to non-corporate domains or USB devices.

8.12 – Data Leakage Prevention: Are technical controls in place to prevent unauthorized transfer or disclosure of sensitive data?

✅ Yes – DLP tools are active and tuned to biotech data

⚠️ Partially – Alerts exist, but no blocking or tuning

❌ No – No data exfiltration controls

8.13 – Information Backup: Are critical systems (EHRs, LIMS, ELNs, datasets) backed up, encrypted, and restore-tested?

Example: Patient images and medical diagnostics from radiology systems are backed up to encrypted cloud storage; restore tests are run quarterly for compliance and continuity.

8.13 – Information Backup: Are critical systems (EHRs, LIMS, ELNs, datasets) backed up, encrypted, and restore-tested?

✅ Yes – Automated, secure, and tested backups

⚠️ Partially – Incomplete or untested backups

❌ No – No reliable backup plan

8.14 – Redundancy of Information Processing Facilities: Do systems supporting critical R&D, diagnostics, or care delivery have redundancy to prevent downtime?

Example: Clinical test data or R&D pipelines are mirrored across regions to maintain continuity during outages.

8.14 – Redundancy of Information Processing Facilities: Do systems supporting critical R&D, diagnostics, or care delivery have redundancy to prevent downtime?

✅ Yes – Redundancy planned, documented, and tested

⚠️ Partially – Some redundancy but not end-to-end

❌ No – No high availability design

8.15 – Logging: Are logs collected for access and activity across systems handling sensitive information?

Example: SIEM collects logs from all lab servers, identity platforms, and SaaS tools.

8.15 – Logging: Are logs collected for access and activity across systems handling sensitive information?

✅ Yes – Logs are comprehensive and reviewed

⚠️ Partially – Logging exists but lacks coverage or review

❌ No – Logs are missing or unused

8.16 – Monitoring Activities: Are you actively monitoring infrastructure for security events (e.g., unauthorized access, anomalies)?

Example: Your SIEM solutions flag abnormal access to clinical databases during non-business hours.

8.16 – Monitoring Activities: Are you actively monitoring infrastructure for security events (e.g., unauthorized access, anomalies)?

✅ Yes – Monitoring with defined alerts and incident procedures

⚠️ Partially – Monitoring exists, but lacks proper alerting or action

❌ No – No centralized or proactive monitoring

8.17 – Clock Synchronization: Are timestamps on all systems (especially for audits) synchronized?

Example: NTP syncing for sequencing controllers and production cloud systems.

8.17 – Clock Synchronization: Are timestamps on all systems (especially for audits) synchronized?

✅ Yes – Synced to secure internal/external sources

⚠️ Partially – Some systems synced, others not

❌ No – Clocks managed manually or not at all

8.18 – Use of Privileged Utility Programs: Are powerful admin tools (e.g., SSH, debug tools) access-controlled and monitored?

Example: Use of scripts to modify DBs requires justification and leaves a log trail.

8.18 – Use of Privileged Utility Programs: Are powerful admin tools (e.g., SSH, debug tools) access-controlled and monitored?

✅ Yes – Role-based access and audit logging in place

⚠️ Partially – Access allowed without oversight

❌ No – Tools freely available

8.19 – Installation of Software: Are users restricted from installing software that could introduce risk or violate license/compliance?

Example: Only approved apps are whitelisted on endpoints; cloud installations require ticket approval.

8.19 – Installation of Software: Are users restricted from installing software that could introduce risk or violate license/compliance?

✅ Yes – Software installs are reviewed, restricted, and approved

⚠️ Partially – Users can install with some oversight

❌ No – No installation restrictions or tracking

8.20 – Network Controls: Is your network segmented and secured based on the risk profile of your R&D, diagnostic, or care systems?

Example: Diagnostic systems and patient portals are segmented from general corporate IT and research networks.

8.20 – Network Controls: Is your network segmented and secured based on the risk profile of your R&D, diagnostic, or care systems?

✅ Yes – Segmentation, firewalls, and ACLs enforced

⚠️ Partially – Some separation exists

❌ No – Flat network topology

8.21 – Security of Network Services: Are third-party network services (e.g., cloud, VPN, messaging) validated and securely configured?

Example: Cloud firewalls are configured to restrict SSH/RDP, and vendor SLAs include encryption and access controls.

8.21 – Security of Network Services: Are third-party network services (e.g., cloud, VPN, messaging) validated and securely configured?

✅ Yes – All third-party network services vetted and secured

⚠️ Partially – Services are used but not formally assessed

❌ No – Uncontrolled third-party network use

8.22 – Segregation in Networks: Are production, staging, research, and clinical environments logically separated?

Example: Clinical systems cannot connect to R&D unless routed through approved proxy and firewall rules.

8.22 – Segregation in Networks: Are production, staging, research, and clinical environments logically separated?

✅ Yes – Segmentation enforced with policies and controls

⚠️ Partially – Some logical barriers in place

❌ No – Full network access across systems

8.23 – Information Transfer Policies and Procedures: Are there clear policies and technical controls for transferring sensitive data?

Example: DNA sequence data is encrypted during transmission and shared via SFTP only.

8.23 – Information Transfer Policies and Procedures: Are there clear policies and technical controls for transferring sensitive data?

✅ Yes – Written policy with secure transfer mechanisms enforced

⚠️ Partially – Policies exist but are not enforced with tools

❌ No – Insecure data sharing occurs

8.24 – Agreements on Information Transfer: Are security obligations clearly defined in contracts with CROs, clinics, cloud vendors, or EHR partners?

Example: CRO contracts define encryption, storage, and incident response obligations.

8.24 – Agreements on Information Transfer: Are security obligations clearly defined in contracts with CROs, clinics, cloud vendors, or EHR partners?

✅ Yes – All data transfers are governed by formal contracts

⚠️ Partially – Some agreements lack security terms

❌ No – No agreements in place

8.25 – Electronic Messaging: Is sensitive information (e.g., patients results, IP) protected in all forms of messaging?

Example: Encrypted messaging is enforced for sharing diagnostic results with clinicians; IP shared via internal Slack is restricted and monitored.

8.25 – Electronic Messaging: Is sensitive information (e.g., patients results, IP) protected in all forms of messaging?

✅ Yes – Messaging platforms are secure and monitored

⚠️ Partially – Some encryption, but gaps in enforcement

❌ No – Plain-text messaging of sensitive data

8.26 – Confidentiality or Non-Disclosure Agreements: Do all employees, contractors, and clinical partners sign NDAs when accessing sensitive information?

Example: All lab contractors and interns sign NDAs upon onboarding.

8.26 – Confidentiality or Non-Disclosure Agreements: Do all employees, contractors, and clinical partners sign NDAs when accessing sensitive information?

✅ Yes – NDAs tracked and enforced across roles

⚠️ Partially – Only some roles covered

❌ No – No NDA process

8.27 – Information Security in Development Processes: Is security embedded into all phases of systems and software development?

Example: Developers use secure libraries, SAST tools, and threat modeling in design.

8.27 – Information Security in Development Processes: Is security embedded into all phases of systems and software development?

✅ Yes – Secure SDLC is defined and practiced

⚠️ Partially – Some practices, but inconsistent

❌ No – No NDA process

8.28 – Secure System Architecture and Engineering Principles: Are your systems (apps, medical devices, portals) designed with security principles like least privilege, encryption, and isolation?

Example: A digital diagnostics platform uses encrypted APIs, role-restricted user sessions, and security design reviews during every release.

8.28 – Secure System Architecture and Engineering Principles: Are your systems (apps, medical devices, portals) designed with security principles like least privilege, encryption, and isolation?

✅ Yes – Secure design documented and implemented

⚠️ Partially – Some principles applied but not standardized

❌ No – No security in system design

8.29 – Secure Coding: Are developers trained in secure coding, and do they follow secure coding guidelines?

Example: Devs receive annual training on OWASP Top 10 and must follow secure library usage.

8.29 – Secure Coding: Are developers trained in secure coding, and do they follow secure coding guidelines?

✅ Yes – Guidelines, training, and enforcement in place

⚠️ Partially – Informal or ad hoc training

❌ No – No secure coding policies

8.30 – Security Testing in Development and Acceptance: Do you conduct security testing (e.g., code reviews, scans) before deploying software?

Example: Every major release undergoes SAST scans, peer review, and penetration testing.

8.30 – Security Testing in Development and Acceptance: Do you conduct security testing (e.g., code reviews, scans) before deploying software?

✅ Yes – Testing is mandatory in the release pipeline

⚠️ Partially – Some testing, but not enforced

❌ No – No structured testing

8.31 – Outsourced Development: Is outsourced software development governed by contractual and technical controls?

Example: External developers work within a secure VDI, follow coding standards, and undergo access review.

8.31 – Outsourced Development: Is outsourced software development governed by contractual and technical controls?

✅ Yes – Contracts include security clauses and oversight

⚠️ Partially – Contracts exist, but controls are weak

❌ No – No control over external development

8.32 – Change Management: Is there a structured process for changes to healthcare platforms, lab systems, or backend APIs?

Example: Changes to a remote diagnostics API or mobile health dashboard undergo formal review with version control, rollback, and security sign-off.

8.32 – Change Management: Is there a structured process for changes to healthcare platforms, lab systems, or backend APIs?

✅ Yes – Change control policies and records exist

⚠️ Partially – Some change tracking; lacks structure

❌ No – Changes made without approval

8.33 – Test Information: Is test data anonymized or synthetic, especially where clinical or patient data is involved?

Example: QA environments use de-identified synthetic records and are isolated from production.

8.33 – Test Information: Is test data anonymized or synthetic, especially where clinical or patient data is involved?

✅ Yes – Test data is non-sensitive and controlled

⚠️ Partially – Real data used, but with some precautions

❌ No – Live data reused in testing

8.34 – Protection of Development and Test Environments: Are dev/test systems isolated, access-controlled, and monitored?

Example: Developers use MFA and VPN to access isolated environments with logging enabled.

8.34 – Protection of Development and Test Environments: Are dev/test systems isolated, access-controlled, and monitored?

✅ Yes – Environments are isolated, and access is governed

⚠️ Partially – Environments partially protected

❌ No – Dev/test systems are open