ISO 27001 Implementation Guide for Educational Institutions: A Practical Roadmap

Executive Summary

This guide provides a practical, actionable roadmap for implementing ISO/IEC 27001:2022 in educational institutions. Designed for college and university administrators, IT directors, and security officers, this guide translates the ISO 27001 standard into concrete steps, templates, and timelines adapted to the unique constraints and opportunities of higher education.

Implementation Timeline: 18-24 months Estimated Resource Requirements: 2-4 FTE dedicated staff, external consultant support for gap analysis and audit Budget Range: ₱2.8M-8.4M PHP (excluding tooling investments)

Key Success Factors:

Executive leadership commitment from senior academic administration
Cross-functional steering committee with faculty representation
Integration with existing IT governance frameworks
Phased approach respecting academic calendar constraints
Cultural alignment with academic freedom principles

How to Use This Guide

This implementation guide is structured chronologically across four major phases spanning 18-24 months. Each phase includes:

Objectives: What you’re trying to achieve
Key Activities: Step-by-step tasks with responsibility assignments
Deliverables: Concrete outputs you must produce
Educational Context Notes: Adaptations specific to colleges/universities
Templates: Ready-to-customize documents
Success Metrics: How to measure progress

Prerequisites Before Starting:

Senior leadership approval and budget allocation
Designated ISMS project manager (0.5-1.0 FTE)
Steering committee established with representatives from IT, faculty, administration, legal
Basic understanding of current information security posture

Companion Resources:

For theoretical background and research synthesis, see: “Creating an Implementation Guide for ISO 27001 in Educational Institutions: A Research Synthesis”
This guide assumes familiarity with ISO 27001:2022 standard structure (available from ISO.org)

Phase 1: Foundation and Scoping (Months 1-4)

Objectives

Define ISMS scope boundaries
Secure leadership commitment
Establish governance structure
Conduct initial gap analysis
Build implementation roadmap

1.1 Establish Governance Structure

Activity 1.1.1: Form ISMS Steering Committee

Composition for educational institutions should include:

Role	Representation	Time Commitment
Executive Sponsor	VP/Provost level	2 hrs/month
ISMS Project Manager	IT Director/Security Officer	20-40 hrs/week
Faculty Representative	Senior faculty member	4 hrs/month
IT Infrastructure Lead	Network/Systems Manager	8 hrs/week
Academic IT Representative	Learning Management System admin	4 hrs/month
Legal/Compliance Officer	General Counsel representative	4 hrs/month
HR Representative	Human Resources	2 hrs/month
Student Affairs Representative	Dean of Students office	2 hrs/month

Deliverable: Steering Committee Charter documenting:

Committee authority and decision-making scope
Meeting cadence (recommended: bi-weekly during implementation)
Escalation procedures
Reporting structure to senior leadership

Educational Context Note: Faculty representation is critical for buy-in. Academic culture values shared governance; unilateral IT mandates will face resistance. Position ISMS as protecting academic freedom through security, not restricting it.

Activity 1.1.2: Define ISMS Scope

ISO 27001 requires clearly defined scope boundaries. For educational institutions, recommended approaches:

Option A: Campus-Wide Scope (Comprehensive but resource-intensive)

Covers: All administrative systems, academic IT infrastructure, research data systems, student information systems
Excludes: Autonomous research labs with separate funding, third-party vendor systems beyond institution control
Best for: Medium-to-large institutions with mature IT centralization

Option B: Critical Systems Scope (Pragmatic starting point)

Covers: Student Information System (SIS), Learning Management System (LMS), Financial/HR systems, Email/authentication infrastructure
Excludes: Departmental systems, faculty-managed research systems, non-critical web properties
Best for: Smaller institutions or initial certification scope with expansion plans

Option C: Hybrid Scope (Balanced approach)

Covers: Core administrative systems + high-risk research data (HIPAA, export-controlled, sensitive student data)
Includes: Baseline security requirements for excluded systems through policy
Best for: Research-intensive universities balancing autonomy with security

Scope Definition Template:

ISMS Scope Statement

In Scope:
- Physical locations: [List specific buildings, data centers]
- Information systems: [List by category - see examples above]
- Data classifications: [All institutional data rated Confidential or above]
- User populations: [Faculty, staff, students, contractors accessing in-scope systems]
- Third-party services: [Cloud providers, SaaS platforms with data processing agreements]

Out of Scope:
- [Explicitly list exclusions with justification]
- [Note: Exclusions cannot eliminate security risks; they must be genuinely outside organizational control]

Justification:
[2-3 paragraphs explaining scope decisions in context of institutional mission and risk tolerance]

Approved by: [Name, Title, Date]
Review date: [Annual recommended]

Deliverable: Approved ISMS Scope Statement, endorsed by steering committee and executive sponsor

Activity 1.1.3: Conduct Gap Analysis

A gap analysis identifies the delta between current security posture and ISO 27001 requirements across:

Clause 4-10 requirements: Context, leadership, planning, support, operation, performance evaluation, improvement
93 Annex A controls: Organizational, people, physical, technological controls

Gap Analysis Methodology:

Document Review (Week 1-2)
- Collect existing policies, procedures, security documentation
- Review past security assessments, audit reports, incident logs
- Inventory current controls (firewall rules, access control lists, training records)
Interviews and Workshops (Week 3-4)
- Interview stakeholders across IT, faculty, administration
- Conduct control workshops for each Annex A theme
- Document current practices vs. required practices
Technical Assessment (Week 5-6)
- Vulnerability scanning of in-scope systems
- Configuration audits against baseline standards
- Access control review (privileged accounts, role assignments)
Gap Scoring (Week 7)
- Rate each control: Fully Implemented (3), Partially Implemented (2), Not Implemented (1), Not Applicable (0)
- Prioritize gaps by risk impact and implementation effort
- Calculate compliance percentage: (Sum of scores / Maximum possible score) × 100

Gap Analysis Template (Excerpt for Annex A.5 Organizational Controls):

Control	Requirement	Current State	Gap Score	Priority	Effort
A.5.1	Policies for information security	Outdated policy from 2018, no annual review	Partially (2)	High	Medium
A.5.2	Information security roles and responsibilities	IT staff have roles, faculty/students unclear	Partially (2)	High	Low
A.5.3	Segregation of duties	No formal SOD matrix, some conflicts identified	Not Implemented (1)	Medium	Medium
A.5.7	Threat intelligence	No formal threat intel feeds or process	Not Implemented (1)	Medium	High

Deliverable: Gap Analysis Report with:

Current compliance percentage (typical educational institutions: 35-55% at baseline)
Prioritized list of 20-30 high-priority gaps
Estimated remediation effort and costs
Risk assessment of major gaps

Educational Context Note: Research institutions may score higher on technical controls (firewalls, encryption) but lower on organizational controls (policies, training, third-party management). Liberal arts colleges may have opposite pattern.

1.2 Define Context and Risk Management Approach

Activity 1.2.1: Identify Internal and External Context (ISO Clause 4.1)

Understanding organizational context shapes risk assessment and control selection.

External Context for Educational Institutions:

Regulatory environment: FERPA, state privacy laws, accreditation requirements
Funding dependencies: Government grants, donor expectations for data protection
Threat landscape: Ransomware targeting education, credential theft, research IP theft
Peer benchmarking: Security expectations from peer institutions
Technology trends: Cloud migration, BYOD, remote learning platforms

Internal Context for Educational Institutions:

Mission alignment: Security supporting educational access vs. restricting it
Governance structure: Shared governance, faculty autonomy, decentralized IT
Resource constraints: Limited security budgets, competing priorities
Culture: Academic freedom, openness, collaborative research
Infrastructure: Legacy systems, diverse technology stack, seasonal usage patterns

Deliverable: Context Analysis Document (4-6 pages) identifying key factors influencing ISMS design

Activity 1.2.2: Identify Interested Parties (ISO Clause 4.2)

Stakeholders with security expectations:

Interested Party	Expectations	How ISMS Addresses
Students	Privacy of educational records, secure access to systems	FERPA compliance controls, secure authentication
Faculty	Protection of research data, academic freedom preserved	Data classification allowing appropriate sharing, minimal restrictions on approved research
Administration	Regulatory compliance, reputation protection	Compliance mapping, incident response procedures
Researchers	Secure infrastructure for sensitive research (HIPAA, export control)	Specialized controls for high-risk research data
Funding Agencies	Grant data security requirements (NIH, NSF)	Alignment with federal security frameworks (NIST 800-171)
Accreditors	Information security as part of institutional accreditation	Documentation demonstrating systematic security management
Alumni/Donors	Protection of gift records, financial data	PCI-DSS integration for payment systems
IT Staff	Clear security procedures, manageable workload	Documented processes, automation where possible

Deliverable: Interested Parties Matrix with expectations documented

Activity 1.2.3: Establish Risk Assessment Methodology

ISO 27001 requires a systematic risk assessment process. Educational institutions should adapt this to academic context:

Risk Assessment Framework for Education:

Asset Identification:

Information assets: Student records, research data, financial data, intellectual property
System assets: SIS, LMS, ERP, authentication systems, research computing
Service assets: Email, network access, cloud storage
People assets: IT staff with privileged access, researchers with sensitive data

Threat Identification (Education-Specific):

External threats: Ransomware, phishing, DDoS attacks, nation-state research espionage
Internal threats: Malicious insiders (rare), negligent data handling (common), compromised credentials
Environmental threats: Power outages, natural disasters affecting data centers
Third-party threats: Vendor breaches, cloud provider outages

Vulnerability Assessment:

Technical vulnerabilities: Unpatched systems, misconfigured cloud storage, weak passwords
Process vulnerabilities: Inconsistent access reviews, no data backup testing, unclear incident response
People vulnerabilities: Insufficient security awareness, social engineering susceptibility

Risk Calculation:

Risk Level = Likelihood × Impact

Likelihood Scale (1-5):
1 = Rare (< 5% annual probability)
2 = Unlikely (5-25% annual probability)
3 = Possible (25-50% annual probability)
4 = Likely (50-75% annual probability)
5 = Almost Certain (> 75% annual probability)

Impact Scale (1-5):
1 = Minimal (< ₱560K financial impact, no privacy breach, < 1 day disruption)
2 = Minor (₱560K-2.8M, small privacy breach affecting < 100 individuals, 1-3 days disruption)
3 = Moderate (₱2.8M-14M, privacy breach affecting 100-1000, 3-7 days disruption, local media)
4 = Major (₱14M-56M, privacy breach > 1000, 1-4 weeks disruption, national media, accreditation risk)
5 = Severe (> ₱56M, massive privacy breach, > 4 weeks disruption, institution viability threatened)

Risk Matrix:
Likelihood × Impact = Risk Score (1-25)
1-5 = Low (Accept with monitoring)
6-11 = Medium (Mitigate with controls)
12-19 = High (Priority mitigation, senior leadership notification)
20-25 = Critical (Immediate action required, may require accepting residual risk if mitigation infeasible)

Risk Treatment Options:

Mitigate: Implement controls to reduce likelihood or impact (most common)
Accept: Document acceptance of residual risk (require executive approval for High/Critical)
Transfer: Insurance, outsourcing to specialized vendors
Avoid: Discontinue high-risk activity (rare in education - may conflict with academic mission)

Deliverable: Risk Assessment Methodology Document (10-15 pages) with:

Asset classification scheme
Threat catalog adapted to education
Likelihood and impact scales calibrated to institution size
Risk acceptance criteria and approval authority matrix
Risk treatment decision framework

1.3 Develop ISMS Policy and Objectives

Activity 1.3.1: Draft Information Security Policy

The top-level information security policy is the foundational ISMS document.

Educational Institution Security Policy Template:

# Information Security Policy
[Institution Name]

## 1. Purpose and Scope

This policy establishes [Institution Name]'s commitment to protecting information assets that support our educational mission, research activities, and administrative operations. This policy applies to all faculty, staff, students, contractors, and third parties accessing institutional information systems within the scope of our Information Security Management System (ISMS).

ISMS Scope: [Reference scope statement from Activity 1.1.2]

## 2. Security Principles

[Institution Name] is committed to:

- **Confidentiality**: Protecting sensitive information from unauthorized disclosure while supporting academic collaboration and the free exchange of ideas
- **Integrity**: Ensuring accuracy and completeness of information and preventing unauthorized modification
- **Availability**: Maintaining reliable access to information systems supporting teaching, learning, research, and administration
- **Compliance**: Meeting legal, regulatory, and contractual obligations including FERPA, state privacy laws, and grant requirements
- **Academic Freedom**: Implementing security controls that protect institutional assets while preserving faculty autonomy in research and pedagogy

## 3. Security Objectives

[Institution Name] commits to:

1. Protecting student educational records in compliance with FERPA and state privacy laws
2. Securing research data according to funder requirements and ethical research standards
3. Maintaining availability of critical systems to support academic operations (target: 99.5% uptime for Tier 1 systems)
4. Detecting and responding to security incidents within defined timeframes (Critical: < 1 hour, High: < 4 hours, Medium: < 24 hours)
5. Conducting annual security awareness training for 95% of faculty and staff
6. Maintaining current risk assessment and treatment plan reviewed at least annually
7. Achieving ISO 27001 certification within [timeframe]

## 4. Roles and Responsibilities

- **Executive Leadership**: Provide resources, approve risk acceptance decisions, champion security culture
- **ISMS Steering Committee**: Oversee ISMS implementation, review major security decisions, ensure alignment with institutional mission
- **Chief Information Security Officer (CISO) / Designee**: Manage day-to-day ISMS operations, coordinate risk assessments, report to leadership
- **Information Asset Owners**: Classify data, approve access, ensure appropriate controls for their information domains
- **IT Staff**: Implement technical controls, monitor systems, respond to incidents
- **All Users**: Follow security policies, report suspected incidents, complete required training

## 5. Risk Management Approach

[Institution Name] employs a risk-based approach to information security:

- Conduct comprehensive risk assessments annually and following major changes
- Prioritize controls based on risk to institutional mission and regulatory requirements
- Accept residual risks only with documented approval from appropriate authority
- Integrate security into project planning and system acquisition processes

## 6. Compliance and Enforcement

Violations of this policy may result in:
- Suspension of system access
- Disciplinary action in accordance with applicable faculty, staff, or student conduct policies
- Legal action in cases of criminal activity
- Termination of contracts for third parties

## 7. Policy Review and Maintenance

This policy will be reviewed at least annually and updated as needed to reflect:
- Changes in risk landscape
- New regulatory requirements
- Lessons learned from security incidents
- Feedback from ISMS audits and reviews

Approved by: _________________________ Date: _________
[President / Provost]

Next Review Date: _________

Deliverable: Approved Information Security Policy signed by executive leadership

Activity 1.3.2: Define Measurable Security Objectives

ISO 27001 requires measurable objectives. Educational institutions should set objectives that balance security with mission:

Example ISMS Objectives for Educational Institutions:

Objective	Measurement	Target	Baseline	Timeline
Protect student data privacy	Zero FERPA violations requiring Department of Education reporting	0 reportable incidents	0 in past 3 years	Maintain annually
Ensure system availability	Uptime for Tier 1 systems (SIS, LMS, Email)	99.5%	Current 97.8%	Month 12
Security awareness	Percentage of employees completing annual training	95%	62%	Month 8
Vulnerability management	Mean time to patch critical vulnerabilities	< 7 days	18 days	Month 6
Incident response	Mean time to detect security incidents	< 24 hours	Unknown (no monitoring)	Month 9
Access control	Percentage of accounts with annual access review	100%	0% (no formal process)	Month 12
Third-party risk	Percentage of critical vendors with security assessments	100%	35%	Month 18

Deliverable: ISMS Objectives Document with baseline, targets, measurement methodology, and responsible parties

Phase 1 Deliverables Checklist

Steering Committee Charter with membership confirmed
ISMS Scope Statement approved by executive sponsor
Gap Analysis Report with prioritized remediation roadmap
Context Analysis Document (internal/external factors)
Interested Parties Matrix
Risk Assessment Methodology Document
Information Security Policy approved and published
ISMS Objectives with measurable targets
Detailed implementation roadmap for Phases 2-4 with resource allocation

Phase 1 Success Metrics:

Executive sponsor formally committed with budget allocated
Steering committee meeting regularly (100% of scheduled meetings held)
Gap analysis identifying 30-50 prioritized remediation items
At least 8 of 10 key stakeholder groups represented in interested parties analysis

Phase 2: Control Implementation (Months 5-14)

Objectives

Implement prioritized Annex A controls
Develop supporting policies and procedures
Deploy technical security controls
Establish operational security processes
Conduct training and awareness programs

2.1 Organizational Controls (Annex A.5)

Activity 2.1.1: Develop Information Security Policy Suite

Beyond the top-level policy, educational institutions need specific policy documents:

Required Policy Documents for Education:

Acceptable Use Policy (AUP)
- Scope: All users of institutional IT resources
- Key provisions:
  - Permitted uses aligned with educational mission
  - Prohibited uses (illegal activity, commercial purposes, harassment)
  - Privacy expectations (“limited privacy” on institutional systems)
  - Consequences of violations
- Educational adaptation: Balance security with academic freedom; avoid overly restrictive language that could chill legitimate research
Data Classification and Handling Policy
- Classification levels:
  - Public: Information intended for public release (course catalogs, public research publications)
  - Internal: Information for institutional use (internal memos, non-sensitive business data)
  - Confidential: Information requiring protection (student records, HR data, most research data)
  - Restricted: Highly sensitive information (SSNs, financial account numbers, HIPAA data, export-controlled research)
- Handling requirements by classification:
  - Storage: Encryption requirements, approved platforms
  - Transmission: Email vs. secure file transfer
  - Sharing: Internal vs. external sharing rules
  - Retention: Aligned with records retention schedules
  - Disposal: Secure deletion/destruction methods
Access Control Policy
- Principle of least privilege
- Role-based access control (RBAC) approach
- Access request and approval workflow
- Periodic access reviews (annually minimum for standard access, quarterly for privileged access)
- Account lifecycle management (provisioning, changes, deprovisioning)
- Password requirements (aligned with NIST guidelines - favor length over complexity, support multi-factor authentication)
- Multi-factor authentication (MFA) requirements for:
  - Administrative access to all systems
  - Remote access to institutional systems
  - Access to restricted data classifications
Incident Response Policy
- Incident definition and classification
- Reporting procedures (how to report, to whom, when)
- Response procedures by severity
- Communication protocols (internal, external, media, law enforcement)
- Post-incident review requirements
Third-Party Security Policy
- Vendor risk assessment requirements
- Security requirements in contracts (data processing agreements, right to audit, notification of breaches)
- Vendor access management
- Vendor monitoring and periodic reassessment
Physical Security Policy
- Data center access controls
- Server room environmental controls
- Workstation security (screen lock, encryption)
- Visitor management
- Asset tracking and disposal
Cryptography Policy
- Approved encryption algorithms (AES-256, TLS 1.2+)
- Encryption requirements by data classification
- Key management procedures
- Certificate management
Backup and Recovery Policy
- Backup schedules by system criticality
- Backup testing requirements (at least annual restoration tests)
- Recovery time objectives (RTO) and recovery point objectives (RPO) by system tier
- Off-site backup storage requirements

Educational Context Note: Policies should be written in accessible language, not dense legalese. Consider creating student-friendly versions of key policies (especially AUP). Faculty senate review and endorsement of policies increases compliance.

Deliverable: Complete policy suite (8-12 policy documents) approved through institutional governance processes

Activity 2.1.2: Define Information Security Roles and Responsibilities (Control A.5.2)

ISO 27001 requires clear assignment of information security responsibilities.

ISMS Role Structure for Educational Institutions:

Role	Typical Job Title	Key Responsibilities	Decision Authority
Information Security Manager (ISM)	CISO, IT Security Director	Overall ISMS management, risk assessment coordination, policy development, audit liaison	Approve standard risk treatments, incident response procedures, control selection
Information Asset Owners (IAO)	Registrar (student data), CFO (financial data), VP Research (research data), HR Director (employee data)	Data classification, access approval for their domain, control adequacy assessment	Approve access to their information assets, accept residual risks for their assets
System Owners	Application managers, infrastructure leads	Implement technical controls, maintain system security configurations, coordinate patching	Approve system changes, emergency maintenance windows
Incident Response Team	IT security staff, network engineers, legal counsel	Detect, analyze, contain, remediate, and recover from security incidents	Authority to isolate systems during active incidents
Data Protection Officer (DPO)	Compliance officer, legal counsel	Privacy compliance, FERPA oversight, breach notification coordination	Approve privacy impact assessments, determine breach notification requirements
Security Awareness Coordinator	IT training staff, faculty development	Develop and deliver security training, phishing simulations, awareness campaigns	Approve training content, schedule training

Responsibility Assignment Matrix (RACI) for Key ISMS Activities:

Activity	ISM	IAO	System Owner	Incident Response Team	DPO	ISMS Steering Committee
Annual risk assessment	R	C	C	I	I	A
Security policy updates	R	C	I	I	C	A
Access grant approvals	I	A/R	C	I	C	I
Incident response	C	I	C	R/A	C	I (for major)
Vendor security review	R	A	C	I	C	I
Control effectiveness monitoring	R	I	C	C	I	I
Audit coordination	R	C	C	I	C	A (audit findings)

R = Responsible (does the work) A = Accountable (final approval) C = Consulted (input requested) I = Informed (kept updated)

Deliverable:

ISMS Roles and Responsibilities Document
RACI matrix for all major ISMS processes
Updated job descriptions incorporating security responsibilities

Activity 2.1.3: Implement Segregation of Duties (Control A.5.3)

Segregation of duties (SOD) prevents single individuals from having end-to-end control over critical processes.

SOD Matrix for Educational Institutions:

Critical Process	Incompatible Duties	Recommended Separation
Financial aid processing	Award approval AND disbursement execution	Financial Aid Officer approves, Bursar executes payment
Grade changes	Grade entry AND audit trail modification	Faculty enter grades, IT cannot alter without formal documented request
System administration	Production system admin AND security audit log admin	Separate roles; logs sent to SIEM managed by security team
User account management	Account creation AND privileged access grant	Help desk creates standard accounts, ISM approves privileged access
Vendor payment	Vendor creation AND payment approval	Accounts Payable creates vendor, different staff approves payments

Small Institution Adaptation: Where staffing prevents full SOD, implement compensating controls:

Enhanced logging and monitoring
Periodic independent reviews
Required dual approval for high-risk transactions
Documented acceptance of SOD conflict with executive approval

Deliverable: SOD Matrix with conflicts identified, separated where possible, compensating controls documented for unavoidable conflicts

2.2 People Controls (Annex A.6)

Activity 2.2.1: Implement Security Awareness and Training Program (Control A.6.3)

Security awareness is critical in educational environments where users are diverse and turnover is high (students).

Multi-Tiered Training Program:

Tier 1: All Users (Faculty, Staff, Students)

Format: Online course, 20-30 minutes
Frequency: Annually + at account creation for new users
Topics:
- Password security and MFA usage
- Recognizing phishing and social engineering
- Safe web browsing and download practices
- Mobile device security (BYOD guidance)
- Reporting suspicious activity
- Data classification basics
- Physical security (locking screens, securing devices)
- Incident reporting procedures
Delivery: LMS-based course with knowledge check (80% pass required)
Tracking: Automated compliance reporting to management

Tier 2: Faculty and Staff with Data Access

Format: Online course + optional in-person workshop, 45-60 minutes
Frequency: Annually
Additional Topics:
- FERPA requirements and student privacy
- Data handling procedures by classification
- Secure collaboration with external parties
- Insider threat awareness
- Social media security
- Secure remote work practices
Delivery: Role-specific modules based on data access

Tier 3: IT Staff and Privileged Users

Format: Technical training, 3-4 hours
Frequency: Annually + updates for major technology changes
Topics:
- Secure system administration
- Vulnerability management
- Incident response procedures (tabletop exercises)
- Secure coding practices (for developers)
- Cloud security configurations
- Threat intelligence and attack trends
Delivery: Combination of external training, vendor certifications, internal workshops

Tier 4: Leadership and High-Risk Roles

Format: Executive briefing, 60-90 minutes
Frequency: Annually
Topics:
- Risk governance and decision-making
- Legal and regulatory landscape
- Third-party risk management
- Business continuity and crisis communications
- Board reporting on security posture
Delivery: Executive session with external experts

Supplementary Awareness Activities:

Monthly security tips via email/newsletter
Quarterly phishing simulations (start at 20-30% click rate, target < 5% over time)
Security awareness month activities (October - National Cybersecurity Awareness Month)
Posters and signage in computer labs and common areas
New employee orientation security module
Student orientation security briefing

Educational Context Note: Students may resist mandatory training. Consider:

Gamification (leaderboards, certificates, prizes)
Embedding in existing orientation programs
Faculty champions to model compliance
Clear messaging: “We protect your data because we respect you”

Deliverable:

Training curriculum with materials for all tiers
Training delivery and tracking system
Annual training completion report (target: 95% compliance)

Activity 2.2.2: Background Screening for Privileged Access (Control A.6.1)

Educational institutions must balance security with employment law and academic culture.

Background Screening Policy for Education:

Role Category	Screening Level	Justification
Privileged IT access (system admins, database admins, security staff)	Level 2: Criminal history check (7 years), education verification, employment verification	Access to sensitive data and critical systems
Financial system access	Level 2: Criminal history + credit check (where permitted by state law)	Access to financial assets, fraud risk
FERPA data access (Registrar, student services)	Level 1: Criminal history check (7 years)	Student privacy protection
Faculty and general staff	Level 0: Credential verification only	Academic freedom considerations; lower risk for general campus systems
Student workers with data access	Level 1: Criminal history check (limited scope)	Balance student employment access with data protection
Contractors with system access	Level 2: Per contractor policy	Third-party risk management

Educational Context Note:

Faculty hiring emphasizes academic credentials over background checks; security screening may be contentious
Some states limit employer use of credit checks; consult legal counsel
International faculty may have limited US criminal history; establish alternative verification
Student background checks must comply with financial aid and FERPA rules

Deliverable: Background Screening Procedures integrated with HR onboarding, documented exceptions process

2.3 Physical Controls (Annex A.7)

Activity 2.3.1: Implement Physical Security Controls

Educational campuses have unique physical security challenges: open environments, public access, distributed facilities.

Layered Physical Security Approach:

Layer 1: Campus Perimeter

Open campus model (typical for colleges) - no perimeter access control
Signage indicating private property
Campus security/police patrols
Emergency call boxes and camera coverage in public areas

Layer 2: Building Access

Administrative buildings: Card access after hours, open during business hours with visitor sign-in
Academic buildings: Generally open during class hours, card access evenings/weekends
Residential halls: Card access 24/7, resident access only
Research buildings: Card access based on research requirements (export control, hazardous materials)

Layer 3: Secure Areas (Data Centers, Server Rooms, Network Closets)

Access Control:
- Card reader + PIN or biometric
- Access limited to authorized IT staff (maintain access list, quarterly review)
- Visitor access only with escort, visitor log maintained
Monitoring:
- 24/7 video surveillance with 90-day retention
- Door alarm on unauthorized access
- Environmental monitoring (temperature, humidity, water detection)
Physical Protection:
- Reinforced doors and locks
- Fire suppression (pre-action sprinkler or gas system)
- Redundant HVAC
- Uninterruptible power supply (UPS) + backup generator
Clear Desk/Clear Screen:
- Policy requiring screen lock after 10 minutes idle
- Sensitive documents secured at end of day
- Printer/copier security (secure print release for confidential documents)

Layer 4: Asset Management

Inventory: All IT assets tagged and tracked (annual physical inventory)
Secure Disposal:
- Data-bearing devices: Cryptographic erasure or physical destruction
- Certificate of destruction for drives with restricted data
- E-waste recycling through certified vendors
Equipment Maintenance:
- Escorts required for vendor maintenance in secure areas
- Data sanitization before equipment leaves site for repair

Educational Context Note:

Balance open academic environment with security zones
Student access to labs and research facilities requires thoughtful access control design
Lost/stolen laptop program for students (insurance, tracking software, encryption requirements)

Deliverable:

Physical Security Standards document
Data center access control list with quarterly review process
Asset inventory system with disposal tracking

2.4 Technological Controls (Annex A.8)

Activity 2.4.1: Implement Identity and Access Management (Controls A.5.15-A.5.18, A.8.2-A.8.5)

Technical Implementation Roadmap:

Week 1-4: Single Sign-On (SSO) Deployment

Technology: SAML 2.0 or OAuth 2.0-based SSO (e.g., Shibboleth, Azure AD, Okta, Google Workspace)
Integration targets (prioritize):
- Student Information System
- Learning Management System
- Email/Office 365/Google Workspace
- HR/Financial systems
- Library systems
Benefits: Reduces password fatigue, centralizes access control, improves user experience
Educational context: Most academic vendors support SAML; prioritize student-facing systems first

Week 5-8: Multi-Factor Authentication (MFA) Rollout

Technology: TOTP (Google Authenticator, Microsoft Authenticator), SMS (backup only), hardware tokens (for privileged users)
Phased rollout:
- Phase 1: IT staff and administrative system access
- Phase 2: Faculty and staff for all systems
- Phase 3: Students for student-facing systems
- Phase 4: VPN and remote access (enforce immediately)
User support: Clear setup guides, IT help desk training, drop-in support sessions
Bypass procedures: Time-limited bypass codes for account recovery, documented approval process

Week 9-12: Privileged Access Management (PAM)

Technology: CyberArk, BeyondTrust, or open-source alternatives (Teleport, HashiCorp Vault)
Privileged accounts to manage:
- Domain administrator accounts
- Database administrator accounts
- Cloud platform admin accounts (AWS, Azure, GCP)
- Network device admin access
- Application service accounts
Features:
- Just-in-time access (request-approval-access-auto-revoke)
- Session recording for audit
- Password rotation (service accounts rotated every 90 days)
- Break-glass emergency access with full logging

Week 13-16: Access Review Automation

Quarterly reviews for privileged access
Annual reviews for standard access
Automated workflow: Generate access reports → send to managers/asset owners → approve/revoke → enforce changes
Risk-based prioritization: Focus reviews on high-risk systems and privileged accounts first

Educational Context Adaptations:

Faculty may resist MFA as “inconvenient”; emphasize protecting their research and reputation
Student accounts: Automate provisioning from SIS, auto-disable after graduation (with grace period for alumni access transitions)
Adjunct faculty and temporary staff: Define clear account lifecycle (provision at hire, auto-disable at term end)
Guest accounts: Time-limited access for visiting scholars, seminar speakers (max 90 days, sponsor approval required)

Deliverable:

SSO integrated with top 10 institutional applications
MFA enforced for 100% of administrative access, 90%+ of general user access
PAM solution managing all privileged accounts
Access review process with quarterly completion reports

Activity 2.4.2: Implement Endpoint Security (Controls A.8.7, A.8.8)

Endpoint Security Stack:

Antivirus/Anti-Malware
- Solution: Enterprise endpoint protection (Microsoft Defender for Endpoint, CrowdStrike, SentinelOne)
- Coverage: All institutionally managed Windows and Mac devices
- Configuration: Real-time protection, cloud-delivered protection, automatic updates
- BYOD: Recommend personal antivirus, cannot enforce on non-institutional devices
Endpoint Detection and Response (EDR)
- Capabilities: Behavioral analysis, threat hunting, automated response
- Deployment: Start with servers and high-risk endpoints (IT staff, finance, research data systems)
- Monitoring: 24/7 SOC (internal team or managed service)
Full Disk Encryption
- Technology: BitLocker (Windows), FileVault (Mac), LUKS (Linux)
- Enforcement: Group Policy (Windows), Configuration Profile (Mac), Compliance checking
- Scope: All laptops, all desktops processing confidential/restricted data
- Key escrow: Centralized recovery key management (BitLocker Recovery Keys in AD, FileVault keys in MDM)
Mobile Device Management (MDM)
- Scope: Institutionally owned mobile devices, BYOD with containerization for institutional email
- Features:
  - Remote wipe capability
  - Passcode enforcement (6-digit minimum)
  - Encryption enforcement
  - App whitelisting/blacklisting
  - Conditional access (only managed devices access certain resources)
Patch Management
- Operating systems: Auto-update for workstations (defer 7 days for testing), monthly patching for servers
- Applications: Automated patch deployment for common software (Java, Adobe, browsers)
- Timelines by severity:
  - Critical vulnerabilities: 7 days
  - High vulnerabilities: 30 days
  - Medium/Low: Next regular patch cycle (monthly)
- Exception process: Document and approve patch deferrals (e.g., research systems requiring specific software versions)

Educational Context Note:

BYOD is prevalent; focus on data protection through application-level controls (email containerization, web-based apps requiring MFA)
Student lab computers: Reimage regularly (weekly or daily), use non-persistent virtual desktops where possible
Faculty research workstations: Coordinate patching with research cycles; backup before major updates

Deliverable:

Endpoint protection deployed to 95%+ of managed devices
Full disk encryption on 100% of mobile devices within scope
Patch compliance dashboard showing patch rates by severity and timeline
MDM covering all institutional mobile devices

Activity 2.4.3: Implement Network Security (Controls A.8.20-A.8.22)

Network Segmentation Strategy:

Network Architecture for Educational Institutions:

┌─────────────────────────────────────────────────────────┐
│ Internet                                                 │
└────────────────┬────────────────────────────────────────┘
                 │
          ┌──────▼──────┐
          │   Firewall   │ (Next-gen firewall with IPS/IDS)
          │   DMZ        │
          └──────┬───────┘
                 │
    ┌────────────┼────────────┬──────────────┬─────────────┐
    │            │            │              │             │
┌───▼────┐  ┌───▼────┐  ┌───▼─────┐   ┌────▼──────┐ ┌───▼──────┐
│ Public │  │Student │  │ Faculty/ │   │Administrative│Research │
│Web Tier│  │Network │  │Staff Net │   │   Network    │Network  │
│(DMZ)   │  │(VLAN10)│  │(VLAN 20) │   │  (VLAN 30)   │(VLAN 40)│
└────────┘  └────────┘  └──────────┘   └──────────────┘└─────────┘
                                              │
                                    ┌─────────┴──────────┐
                                    │                    │
                              ┌─────▼─────┐      ┌──────▼──────┐
                              │ Data Center│      │Secure Research│
                              │Tier (VLAN50)│     │(VLAN 60)    │
                              └────────────┘      │ Export Control│
                                                  │ HIPAA/CUI    │
                                                  └──────────────┘

Firewall Rules by Zone:

Source Zone	Destination Zone	Allowed Traffic	Denied (Default)
Internet	Public Web Tier (DMZ)	HTTP/HTTPS (80/443)	All other ports
Student Network	Internet	HTTP/HTTPS, DNS, Email	Direct RDP/SSH to internet (force through VPN)
Student Network	Administrative Network	DENY (except specific approved services: print servers, file shares)	All administrative systems
Faculty/Staff Network	Administrative Network	SIS, ERP, HR systems (application-level access control)	Direct database access
Any	Data Center Tier	Application ports only (no direct DB access except from app servers)	All administrative ports (SSH, RDP, etc. - require PAM)
Administrative Network	Secure Research	Specific individuals approved by IAO	Default deny

Network Security Controls:

Next-Generation Firewall (NGFW): Application-aware firewall with intrusion prevention system (IPS)
Network Access Control (NAC): 802.1X authentication for wired network, WPA2/3-Enterprise for wireless
Wireless Security:
- Institutional SSID: WPA2/3-Enterprise with RADIUS authentication (tied to institutional credentials)
- Guest SSID: Isolated VLAN, captive portal, bandwidth limits, no access to internal resources
- IoT SSID: Separate network for smart building devices, cameras, etc.
Intrusion Detection/Prevention System (IDS/IPS): Monitor for known attack patterns, automatically block malicious traffic
DDoS Protection: Cloud-based DDoS mitigation for public-facing services (Cloudflare, Akamai)
VPN: Required for remote access to administrative systems
- Technology: IPSec or SSL VPN
- MFA enforced for VPN access
- Split tunneling disabled for users accessing restricted data

Educational Context Note:

Open campus networks: Guest access is expected; isolate from internal resources
ResNet (residential network): Student devices are untrusted; segment from administrative systems
Research network isolation: Balance security with collaboration needs; data classification guides segmentation

Deliverable:

Network segmentation implemented with documented VLAN strategy
Firewall rules documented and reviewed quarterly
NAC deployed to administrative network segments (phased rollout to other segments)
IDS/IPS monitoring with alert thresholds tuned to reduce false positives

Activity 2.4.4: Implement Security Monitoring and Logging (Controls A.8.15-A.8.16)

Security Information and Event Management (SIEM) Implementation:

Phase 1: Log Source Identification

Priority log sources for educational institutions:

Tier	System Type	Log Sources	Key Events to Monitor
Tier 1 (Critical)	Authentication	Active Directory, LDAP, SSO provider	Failed login attempts, privilege escalations, account lockouts
	Administrative Systems	SIS, ERP, HR systems	Unauthorized data access, grade changes, financial transactions
	Firewalls	Perimeter firewall, internal segment firewalls	Blocked connections, policy violations
Tier 2 (High)	Endpoints	EDR platform, antivirus	Malware detections, suspicious process execution
	Servers	Windows/Linux servers in scope	Service failures, unauthorized access attempts, privilege use
	Network	Switches, wireless controllers, VPN	Network anomalies, rogue devices
Tier 3 (Medium)	Applications	Web applications, databases	SQL injection attempts, application errors, data exports
	Cloud Services	Office 365/Google Workspace, AWS/Azure	Admin activity, data sharing, configuration changes

Phase 2: SIEM Deployment

Technology Options:
- Commercial: Splunk, Microsoft Sentinel, IBM QRadar
- Open-source: Elastic Stack (ELK), Wazuh, Graylog
- Education-specific: Many vendors offer discounted/free licensing for education
Architecture:
- Centralized SIEM server (on-premise or cloud)
- Log forwarders on critical systems
- Minimum 90-day log retention (180 days for compliance-sensitive systems)
- Long-term archival to low-cost storage (1-year minimum for audit trail)

Phase 3: Use Case Development

Develop detection use cases aligned with educational threat landscape:

Use Case	Description	MITRE ATT&CK Tactic	Alert Threshold
Brute Force Attack	Multiple failed login attempts from single source	Credential Access	> 10 failures in 5 minutes
Privilege Escalation	Standard user account added to admin group	Privilege Escalation	Any occurrence
Data Exfiltration	Large data transfer to external cloud storage	Exfiltration	> 1GB to consumer cloud services
Ransomware Indicators	Mass file encryption activity	Impact	> 100 files with suspicious extensions in 10 minutes
Lateral Movement	Account accessing abnormally high number of systems	Lateral Movement	> 5 systems in 10 minutes (deviation from baseline)
After-Hours Access	Access to restricted systems outside normal hours	Initial Access	Any access to financial systems 10PM-6AM
Impossible Travel	Logins from geographically distant locations in short time	Initial Access	> 500 miles between logins in < 1 hour

Phase 4: Alerting and Response Integration

Alert severity levels:
- Critical: Immediate notification (SMS/phone), 15-minute response SLA
- High: Email + ticket creation, 1-hour response SLA
- Medium: Ticket creation, 4-hour response SLA
- Low: Daily digest report, investigation during business hours
Integration with incident response:
- Automated ticket creation in IT service management (ITSM) system
- Playbooks for common scenarios (phishing, malware, unauthorized access)
- Escalation to Information Security Manager for critical alerts

Educational Context Note:

Seasonal patterns: Expect high activity during registration, finals, start of semester; baseline during these periods
Research systems: May have unique log patterns; work with researchers to distinguish normal from suspicious
Student privacy: Log analysis must respect FERPA; limit access to security team, audit logs of who reviews logs

Deliverable:

SIEM platform deployed with top 20 log sources integrated
15-20 use cases implemented with tested alerting
90-day log retention for all in-scope systems
Monthly SIEM effectiveness report (alert volume, false positive rate, true positive investigations)

2.5 Operational Security Processes

Activity 2.5.1: Establish Vulnerability Management Process (Control A.8.8)

Vulnerability Management Lifecycle:

Discovery (Continuous)
- Automated vulnerability scanning: Weekly for internet-facing systems, monthly for internal systems
- Scanner: Nessus, Qualys, Rapid7, or open-source (OpenVAS)
- Authenticated scans for complete coverage
- Asset discovery to identify rogue/unknown systems
Assessment (Within 48 hours of scan completion)
- Vulnerability prioritization:
  - CVSS score (Common Vulnerability Scoring System)
  - Exploit availability (actively exploited in wild = highest priority)
  - Asset criticality (public-facing + critical data = highest)
  - Compensating controls (firewall blocking vulnerable port = lower priority)
- Risk scoring: Vulnerability severity × Asset criticality × Threat likelihood
Remediation (SLA by severity)
- Critical (CVSS 9.0-10.0, active exploitation): 7 days
- High (CVSS 7.0-8.9): 30 days
- Medium (CVSS 4.0-6.9): 90 days
- Low (CVSS 0.1-3.9): Next maintenance window or accept risk
Verification (Rescan after remediation)
- Confirm vulnerability no longer detected
- Update asset inventory with patch level
Reporting (Monthly)
- Metrics: Open vulnerabilities by severity, mean time to remediate, SLA compliance rate
- Dashboard for steering committee: Trend over time, comparison to previous period
- Exceptions: Document and approve (by IAO and ISM) any vulnerabilities not remediated within SLA

Educational Context Adaptations:

Research systems: Coordinate patching with research cycles; some legacy research apps may not support current OS/software
Classroom technology: Patch during semester breaks when possible
Exception process: Formally document and accept risk for vulnerabilities that cannot be patched due to operational constraints

Deliverable:

Vulnerability scanning scheduled for all in-scope systems
Vulnerability management procedure document
Monthly vulnerability metrics dashboard
Vulnerability exception register

Activity 2.5.2: Establish Incident Response Process (Controls A.5.24-A.5.27)

Incident Response Plan for Educational Institutions:

1. Preparation

Incident Response Team Composition:

Role	Primary	Backup	On-Call Availability
Incident Commander	Information Security Manager	IT Director	24/7 (phone)
Technical Lead	Senior Systems Engineer	Network Engineer	Business hours + on-call
Communications Lead	IT Communications	PR/Marketing	Business hours
Legal Counsel	General Counsel Rep	External Counsel	On-demand
HR Representative	HR Director	HR Manager	Business hours

Incident Classification:

Severity	Definition	Examples	Response SLA
Critical	Significant impact to institutional operations or data breach of restricted data	Ransomware, breach of SSNs, SIS offline	< 15 minutes
High	Moderate impact or breach of confidential data	Phishing campaign, malware on multiple systems, unauthorized access	< 1 hour
Medium	Limited impact, single system or non-sensitive data	Single malware infection, minor policy violation	< 4 hours
Low	Minimal impact, potential security issue	Suspicious email reported, failed login anomaly	< 24 hours

2. Detection and Reporting

Detection Sources:
- SIEM alerts
- EDR alerts
- User reports (phishing, suspicious activity)
- Third-party notifications (vendor breach, law enforcement)
Reporting Mechanisms:
- Primary: security@[institution].edu email (monitored 24/7)
- Secondary: IT Help Desk hotline (transfer to security on-call)
- Self-service: Web form for non-urgent reports

3. Analysis and Containment

Initial Analysis (within SLA):
- Validate incident (not false positive)
- Classify severity
- Activate appropriate response team
- Document in incident tracking system (ServiceNow, JIRA, etc.)

Containment Strategies:

Incident Type	Short-term Containment	Long-term Containment
Malware/Ransomware	Isolate infected system(s) from network	Reimage system, restore from clean backup
Unauthorized Access	Disable compromised account, reset passwords	Review and remove unauthorized access, implement MFA
Phishing Campaign	Block sender domain, remove emails from mailboxes	User education, email filter tuning
DDoS Attack	Activate DDoS mitigation service	Adjust firewall rules, increase capacity
Data Breach	Identify scope of exposure, contain exfiltration path	Revoke access, notify affected parties per policy

4. Eradication and Recovery

Remove threat from environment
Restore systems from known-good backups
Verify systems clean before returning to production
Monitor for signs of persistence or reinfection

5. Post-Incident Activity

Post-Incident Review (within 5 business days for High/Critical incidents):
- What happened (timeline, root cause)
- What worked well in response
- What could be improved
- Action items for improvement
Lessons Learned:
- Update incident response procedures
- Implement additional controls to prevent recurrence
- Share learnings with IT staff and steering committee
Reporting:
- Internal: Incident summary to steering committee (monthly for aggregate, immediately for critical incidents)
- External: Breach notification per legal requirements (FERPA, state laws)
- Regulatory: Report to relevant authorities (HHS for HIPAA, OCR for FERPA if required)

Educational Context Adaptations:

Academic Calendar Awareness: Incidents during finals or registration have higher impact; prioritize recovery
Communication Sensitivities: Student newspaper, social media require careful PR coordination; designate single spokesperson
FERPA Considerations: Protect student privacy during investigation; legal counsel review before disclosure
Research Impact: Coordinate with researchers on lab/research system incidents; data loss may impact publications/grants

Deliverable:

Incident Response Plan (30-40 page document)
Incident response playbooks for top 10 scenarios (phishing, ransomware, unauthorized access, etc.)
Incident response team trained and tabletop exercise conducted
Incident tracking and reporting system operational

Activity 2.5.3: Implement Backup and Recovery (Control A.8.13)

Backup Strategy for Educational Institutions:

Backup Scope and Schedule:

System Tier	Examples	Backup Frequency	Retention	Recovery Time Objective (RTO)	Recovery Point Objective (RPO)
Tier 1 - Mission Critical	Student Information System, Learning Management System, Authentication (AD/LDAP), Email	Continuous replication or hourly incremental	30 days onsite, 1 year offsite	< 4 hours	< 1 hour
Tier 2 - Important	Financial system, HR system, Research data repositories, File servers	Daily incremental, weekly full	14 days onsite, 90 days offsite	< 24 hours	< 24 hours
Tier 3 - Standard	Departmental websites, Internal wikis, Non-critical applications	Weekly full	7 days onsite, 30 days offsite	< 72 hours	< 1 week

3-2-1 Backup Rule:

3 copies of data (production + 2 backups)
2 different media types (disk + tape/cloud)
1 copy offsite (cloud or offsite datacenter)

Backup Testing:

Monthly: Automated restore test of sample files from Tier 1 systems (scripted, alerts on failure)
Quarterly: Manual restore test of full database from Tier 1/2 systems to test environment
Annually: Full disaster recovery exercise simulating complete data center loss

Encryption and Security:

Backups of restricted/confidential data: Encrypted at rest (AES-256)
Transport encryption for backups sent offsite (TLS 1.2+)
Access control: Backup administrators separate from production admins where possible (SOD)
Immutable backups: Use write-once-read-many (WORM) storage or immutable cloud storage to protect against ransomware

Educational Context Adaptations:

Research Data: Coordinate with researchers on backup schedules; some research generates large datasets requiring specialized backup solutions
Academic Calendar: Test restores during low-activity periods (winter/summer breaks)
Student Work: LMS assignments and submissions are tier 1 data during academic term (protect student work)

Deliverable:

Backup procedures document with schedules for all in-scope systems
Backup monitoring dashboard showing successful/failed backups
Quarterly restore test reports
Disaster recovery plan with system recovery priority and procedures

Phase 2 Deliverables Checklist

Phase 2 Success Metrics:

80-90% of Annex A controls implemented (from 35-55% baseline)
All Tier 1 systems have implemented security controls
Security awareness training completion > 90%
MFA adoption > 90% for administrative access
Vulnerability remediation SLA compliance > 85%
Successful quarterly backup restoration tests

Phase 3: Documentation and Internal Audit (Months 15-18)

Objectives

Complete ISMS documentation
Conduct internal audit to identify gaps
Remediate findings
Demonstrate control effectiveness
Prepare for certification audit

3.1 ISMS Documentation Package

ISO 27001 certification requires comprehensive documentation. Educational institutions should organize documentation for efficiency and auditability.

Required Documentation Structure:

ISMS Documentation Repository (SharePoint/Confluence/Document Management System)

/00-ISMS-Foundation
  ├── ISMS-Scope-Statement.pdf
  ├── Information-Security-Policy.pdf
  ├── ISMS-Objectives-and-Targets.pdf
  ├── Context-Analysis.pdf
  └── Interested-Parties-Matrix.pdf

/01-Risk-Management
  ├── Risk-Assessment-Methodology.pdf
  ├── Risk-Assessment-Report-2025.pdf (annual, versioned)
  ├── Risk-Treatment-Plan-2025.pdf
  ├── Risk-Register.xlsx (living document, regularly updated)
  └── Statement-of-Applicability.pdf

/02-Policies-and-Procedures
  ├── /Policies
  │   ├── Acceptable-Use-Policy.pdf
  │   ├── Access-Control-Policy.pdf
  │   ├── Data-Classification-Policy.pdf
  │   ├── Incident-Response-Policy.pdf
  │   ├── [Additional 8-12 policies]
  │
  ├── /Procedures
  │   ├── Access-Request-Procedure.pdf
  │   ├── Incident-Response-Procedure.pdf
  │   ├── Vulnerability-Management-Procedure.pdf
  │   ├── Backup-Recovery-Procedure.pdf
  │   ├── [20-30 operational procedures]
  │
  └── /Standards
      ├── Password-Standard.pdf
      ├── Encryption-Standard.pdf
      ├── Server-Hardening-Standard.pdf
      └── [10-15 technical standards]

/03-Asset-Management
  ├── Asset-Inventory.xlsx
  ├── Data-Flow-Diagrams/ (by major system)
  └── System-Descriptions/ (one-pagers for each major system)

/04-Operations
  ├── /Access-Management
  │   ├── Access-Review-Reports/ (quarterly)
  │   ├── Privileged-Account-Inventory.xlsx
  │
  ├── /Vulnerability-Management
  │   ├── Vulnerability-Scan-Reports/ (monthly)
  │   ├── Vulnerability-Exception-Register.xlsx
  │
  ├── /Incident-Management
  │   ├── Incident-Reports/ (by incident number)
  │   ├── Incident-Response-Playbooks/
  │
  ├── /Backup-Management
  │   ├── Backup-Test-Reports/ (quarterly)
  │   ├── Disaster-Recovery-Plan.pdf
  │
  └── /Training
      ├── Training-Completion-Reports/ (annual)
      ├── Training-Materials/

/05-Monitoring-and-Review
  ├── /Management-Review
  │   ├── Management-Review-Meeting-Minutes/ (quarterly)
  │   ├── Management-Review-Presentations/
  │
  ├── /Performance-Metrics
  │   ├── ISMS-Metrics-Dashboard/ (monthly KPIs)
  │   ├── Security-Incident-Trends/
  │
  └── /Internal-Audits
      ├── Internal-Audit-Plan-2025.pdf
      ├── Internal-Audit-Reports/
      ├── Corrective-Action-Register.xlsx

/06-Statement-of-Applicability
  └── Statement-of-Applicability.pdf (comprehensive control mapping)

Key Document: Statement of Applicability (SOA)

The SOA is the most critical document for certification. It lists all 93 Annex A controls and for each:

Whether it is applicable or not
Justification for exclusion if not applicable
How it is implemented if applicable
Reference to supporting documentation

Sample SOA Entries:

Control	Title	Applicable?	Implementation Status	Implementation Description	Evidence
A.5.1	Policies for information security	Yes	Implemented	Top-level Information Security Policy approved by Provost, supplemented by 12 domain-specific policies. Annual review process established.	Information-Security-Policy.pdf, Policy-Review-Schedule.xlsx
A.5.7	Threat intelligence	Yes	Implemented	Subscribe to US-CERT alerts, Educause Security Advisory, vendor security bulletins. Monthly review of threat intelligence in security team meeting.	Threat-Intel-Sources.xlsx, Security-Team-Meeting-Minutes/
A.5.23	Information security for use of cloud services	Yes	Implemented	Cloud Security Policy defines requirements for cloud service use. Vendor assessment process requires security review for all SaaS/IaaS. Data Processing Agreements required for cloud services processing institutional data.	Cloud-Security-Policy.pdf, Vendor-Assessment-Procedure.pdf, DPA-Template.pdf
A.6.6	Confidentiality or non-disclosure agreements	Yes	Implemented	NDAs required for IT staff, contractors, and vendors with access to restricted data. Templates maintained by Legal.	NDA-Template.pdf, NDA-Tracking-Register.xlsx
A.8.9	Configuration management	Yes	Partially Implemented	Baseline configurations documented for Windows/Linux servers. Configuration management tooling (Ansible) deployed for server builds. Workstation configurations not yet fully standardized (planned for Q3 2025).	Server-Hardening-Standards/, Ansible-Playbooks-Repo, Configuration-Roadmap.pdf
A.7.4	Physical security monitoring	Yes	Implemented	Data center and server rooms have 24/7 video surveillance with 90-day retention. Door access logs reviewed quarterly.	Physical-Security-Procedures.pdf, Access-Log-Review-Reports/
A.8.12	Data leakage prevention	No	Not Applicable	DLP not implemented. Risk accepted due to resource constraints and reliance on data classification + access controls + user training as primary controls. Planned for consideration in next 3-year ISMS planning cycle.	Risk-Acceptance-DLP.pdf (signed by CIO)

Educational Context Note:

Not all 93 controls will be applicable or fully implemented; it’s acceptable to mark controls as “not applicable” with justification or “partially implemented” with roadmap
Common exclusions in education: A.8.12 (DLP - expensive, may mark N/A), some physical controls if cloud-heavy
Focus on demonstrating systematic approach rather than perfection

Deliverable:

Complete ISMS documentation package organized in accessible repository
Statement of Applicability with all 93 controls addressed
Document control procedures (versioning, approval, review cycles)

3.2 Internal Audit

ISO 27001 requires internal audits to verify ISMS effectiveness before certification audit.

Activity 3.2.1: Internal Audit Planning

Audit Scope: All clauses (4-10) and all applicable Annex A controls per SOA

Audit Team:

Option A: Internal team from other departments (finance audit, academic affairs) trained in ISO 27001 auditing
Option B: External consultants (recommended for first audit; provides learning opportunity)
Requirement: Auditors must be independent of the function being audited

Audit Schedule (8-10 weeks):

Week	Audit Activity	Scope
1	Audit planning and document review	ISMS foundation documents, policies, SOA
2	Interviews with ISMS leadership	ISMS project manager, steering committee, executive sponsor
3	Clause 4-7 audit (Context, Leadership, Planning, Support)	Review context analysis, risk assessment, resource allocation, training records
4	Clause 8-10 audit (Operation, Performance, Improvement)	Review operational processes, incident response, management review, corrective actions
5	Annex A.5-A.6 audit (Organizational and People Controls)	Review policies, roles, training, HR procedures
6	Annex A.7 audit (Physical Controls)	Physical inspection of data center, access logs, equipment disposal records
7	Annex A.8 audit (Technological Controls)	Review technical controls, logs, vulnerability scans, configuration baselines
8	Findings compilation and draft report	Document nonconformities and observations
9	Findings review with ISMS team	Clarifications, additional evidence
10	Final audit report	Deliver audit report with findings and recommendations

Deliverable: Internal Audit Plan approved by steering committee

Activity 3.2.2: Conduct Internal Audit

Audit Methodology:

Document Review: Verify policies, procedures, records exist and are current
Interviews: Validate understanding and implementation (talk to help desk, system admins, faculty, students)
Observation: Verify controls in practice (observe backup test, physical access control, security monitoring)
Testing: Sample transactions/activities (test 10 access requests - were they approved properly? test 5 incident response cases - were procedures followed?)

Finding Classifications:

Type	Definition	Example	Certification Impact
Major Nonconformity	Absence of or complete failure of a control; systemic issue	No risk assessment conducted in past year; no incident response process	Will prevent certification; must be corrected before cert audit
Minor Nonconformity	Isolated failure or partial implementation	Access reviews completed but 2 months late; training 85% complete (target 95%)	Must have correction plan; can certify with plan in place
Observation	Area for improvement but not nonconformity	Patch management process works but lacks automation; documentation could be clearer	No certification impact; recommendations for enhancement

Expected Finding Patterns in Education:

Common minor nonconformities:
- Documentation gaps (procedure exists in practice but not documented)
- Incomplete training records
- Delayed access reviews
- Some controls implemented but not consistently applied across all systems
Common observations:
- Opportunity to automate manual processes
- Better integration between security tools
- More proactive threat hunting vs. reactive incident response

Deliverable:

Internal Audit Report with:
- Executive summary
- Audit scope and methodology
- Findings by severity (major nonconformities, minor nonconformities, observations)
- Evidence samples reviewed
- Recommendations for improvement
- Timeline for remediation before certification audit

Activity 3.2.3: Remediate Internal Audit Findings

Corrective Action Process:

For each finding:

Root Cause Analysis: Why did the nonconformity occur? (lack of procedure, procedure not followed, resources insufficient, etc.)
Corrective Action Plan:
- Immediate correction (fix this instance)
- Systemic correction (prevent recurrence)
- Responsible party
- Target completion date
Implementation: Execute corrective actions
Verification: Auditor (or ISMS manager) verifies correction effectiveness
Closure: Document closure in Corrective Action Register

Sample Corrective Action Register:

Finding ID	Finding Description	Severity	Root Cause	Corrective Action	Owner	Due Date	Status	Verification
IA-2025-01	Access reviews not completed for Finance system users in Q4 2024	Minor	Process not calendared, owner unclear	1) Complete overdue review; 2) Add quarterly reviews to ISMS calendar with automated reminders; 3) Update procedure to assign backup reviewer	Finance IAO	2025-06-15	Closed	Review completed, calendar updated, procedure revised - verified 2025-06-20
IA-2025-02	Server hardening baseline missing for Linux research servers	Minor	Research servers not included in original scope	1) Document current configs; 2) Develop baseline standard; 3) Remediate gaps; 4) Add to quarterly config audit	IT Infrastructure	2025-07-01	In Progress	Baseline drafted, awaiting approval
IA-2025-03	Incident response playbook not tested via tabletop exercise	Observation	Planned but delayed due to staffing	Schedule and conduct tabletop in Q3 2025	ISM	2025-09-30	Open	N/A

Timeline: All major nonconformities must be corrected before scheduling certification audit. Minor nonconformities should have documented correction plans.

Deliverable:

Corrective Action Register with all findings addressed
Updated documentation reflecting corrective actions
Verification evidence for corrective actions

3.3 Management Review

ISO 27001 Clause 9.3 requires top management to review the ISMS at planned intervals.

Management Review Cadence: Quarterly during implementation, at least annually post-certification

Management Review Agenda and Inputs:

Status of Actions from Previous Reviews
- Follow-up on decisions and action items from last management review
Changes in External and Internal Issues
- New regulations (FERPA updates, state privacy laws)
- Technology changes (cloud migration, new systems)
- Organizational changes (leadership transitions, restructuring)
Feedback on ISMS Performance
- Achievement of ISMS objectives (metrics dashboard)
- Incident trends (number, severity, types)
- Audit findings (internal and external)
- Compliance status (vulnerability SLAs, training completion)
Feedback from Interested Parties
- Faculty concerns or feedback on security measures
- Student feedback on usability of security controls
- Audit or assessment reports from external parties (accreditors, grantors)
Risk Assessment and Treatment Results
- New risks identified
- Changes to existing risk ratings
- Effectiveness of risk treatments
Opportunities for Continual Improvement
- Process improvements
- Technology enhancements
- Lessons learned from incidents

Management Review Outputs (Decisions and Actions):

Changes to ISMS scope or objectives
Resource allocation decisions (budget, staffing for next period)
Risk acceptance decisions
Policy updates or new control implementations

Educational Context Note:

Schedule management reviews to align with academic calendar (start/end of semester, before budget cycles)
Executive sponsor may delegate attendance to direct report but should personally attend at least annual review
Present data in dashboard format; executives have limited time for lengthy technical reports

Deliverable:

Management Review Meeting Minutes (quarterly)
Management Review Presentation Deck (dashboard of KPIs, risk heat map, top issues)
Action Item Register with assignments and due dates

Phase 3 Deliverables Checklist

Complete ISMS documentation package organized in repository
Statement of Applicability with all 93 controls addressed
Internal audit completed with findings report
All major nonconformities corrected
Corrective action plans for minor nonconformities
Management review conducted with documented decisions
Documentation updated based on audit findings and management review
Pre-certification readiness self-assessment > 95%

Phase 3 Success Metrics:

Zero major nonconformities remaining
< 10 minor nonconformities with documented correction plans
Management review participants include executive sponsor and key stakeholders
ISMS documentation complete and accessible to audit team

Phase 4: Certification Audit (Months 19-24)

Objectives

Complete Stage 1 and Stage 2 certification audits
Address any audit findings
Achieve ISO 27001:2022 certification
Plan for ongoing ISMS maintenance and surveillance audits

4.1 Select Certification Body

Accredited Certification Bodies for ISO 27001:

Certification bodies must be accredited by national accreditation body (e.g., ANAB in US, UKAS in UK)
Verify accreditation scope includes ISO/IEC 27001:2022

Selection Criteria:

Criterion	Considerations
Accreditation	Verify current accreditation for ISO 27001:2022 (not just 27001:2013)
Industry Experience	Preference for auditors with higher education experience (understand academic context)
Geography	Local/regional presence reduces travel costs, familiar with local regulatory context
Cost	Quotes typically ₱840,000-2.24M for Stage 1 + Stage 2 (varies by scope size and organization complexity)
Timeline	Availability to conduct audit in desired timeframe
Reputation	References from other educational institutions
Auditor Quality	Request CV/qualifications of proposed audit team lead

Process:

Request quotes from 3-4 accredited certification bodies (allow 2-3 weeks for quote development)
Provide: ISMS scope statement, employee count, number of sites, list of in-scope systems
Evaluate quotes and select certification body
Sign certification agreement
Schedule Stage 1 audit (typically 8-12 weeks out)

Deliverable: Signed agreement with accredited certification body, audit schedule confirmed

4.2 Stage 1 Audit (Documentation Review)

Purpose: Verify ISMS documentation is complete and ready for Stage 2 audit

Duration: 2-3 days (varies by scope; typical mid-size college: 2 days)

Stage 1 Activities:

Review ISMS scope and boundaries
Review ISMS policies and procedures
Review Statement of Applicability
Review risk assessment and treatment plan
Review evidence of management commitment
Interview ISMS leadership
Review readiness for Stage 2 (Are processes operational? Are records being generated?)

Stage 1 Possible Outcomes:

Proceed to Stage 2: Documentation adequate, recommend scheduling Stage 2
Proceed with observations: Minor documentation gaps noted but can proceed; address before Stage 2
Defer Stage 2: Significant documentation gaps or ISMS not yet operational; remediate before scheduling Stage 2

Stage 1 Typical Findings for Educational Institutions:

Minor documentation gaps (procedure referenced in SOA doesn’t exist or is draft)
Evidence of operational effectiveness limited (ISMS recently implemented, not enough data yet)
Management review minutes don’t cover all required inputs
Statement of Applicability missing justifications for some controls

Remediation Period: Typically 2-4 weeks to address Stage 1 findings before Stage 2 audit

Deliverable:

Stage 1 Audit Report
Corrective actions for any Stage 1 findings
Readiness confirmation to proceed to Stage 2

4.3 Stage 2 Audit (Implementation Audit)

Purpose: Verify ISMS is effectively implemented and operating as documented

Timing: Typically 2-6 months after Stage 1 (allows time to generate operational evidence)

Duration: 3-5 days onsite (varies by scope; typical mid-size college: 4 days)

Stage 2 Activities:

Day 1: Opening Meeting and Leadership Interviews

Opening meeting with executive sponsor, steering committee, ISMS team
Auditor explains process, timeline, clarifies scope
Interviews with executive sponsor, ISMS project manager, IAOs
Review management review records, ISMS objectives performance

Day 2: Clause 4-10 and Organizational/People Controls Audit

Review context analysis and risk assessment process
Examine risk register, treatment plan, residual risk acceptances
Review training records (sample 20-30 employee training completions)
Interview HR on background screening process
Review policy suite and approval evidence

Day 3: Physical and Technological Controls Audit

Physical tour of data center, server rooms
Review access logs, visitor logs
Interview IT staff on technical control implementation
Review vulnerability scan reports, patch management evidence
Examine firewall configurations, network segmentation
Review backup logs and restoration test records
Examine incident logs and response evidence

Day 4: Operational Processes and Sampling

Sample access requests (select 10-15, verify approval process followed)
Sample incidents (select 3-5, trace through response process)
Sample access reviews (verify completion and timeliness)
Review vendor security assessments
Examine SIEM use cases and alert response
Review change management records

Day 5: Findings Review and Closing Meeting

Auditor team compiles findings
Closing meeting: Present findings to ISMS team and leadership
Discuss any nonconformities and required corrective actions
Explain next steps and timeline

Stage 2 Possible Outcomes:

Recommend Certification: No major nonconformities, zero or few minor nonconformities
Conditional Certification: Minor nonconformities found; certification granted contingent on timely correction (typically 90 days)
Defer Certification: Major nonconformities found; must correct and undergo re-audit before certification

Stage 2 Typical Findings for Educational Institutions:

Access reviews completed but some delays (minor nonconformity)
Training completion rate below target (e.g., 88% vs. 95% objective) - minor nonconformity
Some technical controls not consistently applied across all systems (minor nonconformity)
Incident response process followed but documentation incomplete for some incidents (observation)
Backup tests conducted but not all results documented (observation)

Certification Decision Timeline:

Certification body reviews audit report (2-4 weeks)
Issues certificate or requests corrective actions
If corrective actions required: 90 days to complete, submit evidence, certification body reviews and decides

Deliverable:

Stage 2 Audit Report
Corrective Action Plans for any findings
ISO 27001:2022 Certificate (upon successful completion)

4.4 Post-Certification: Ongoing ISMS Maintenance

Surveillance Audits:

Frequency: Annual (once per year for 2 years after initial certification)
Scope: Subset of ISMS (typically 30-40% of controls per surveillance, rotating coverage)
Duration: 1-2 days
Purpose: Verify ISMS continues to operate effectively, address changes, review corrective actions

Recertification Audit:

Frequency: Every 3 years
Scope: Full ISMS review (similar to Stage 2)
Purpose: Renew certification for next 3-year cycle

Ongoing ISMS Activities:

Quarterly: Management review, access reviews for privileged accounts
Annually: Risk assessment update, policy reviews, all-user access reviews, internal audit, training
Continuous: Vulnerability management, incident response, security monitoring, backup testing, change management

ISMS Continuous Improvement:

Incorporate lessons learned from incidents
Respond to changes in threat landscape
Adopt new technologies (AI/ML for security monitoring, automation)
Expand ISMS scope as resources allow
Integrate with other frameworks (COBIT, NIST CSF, CIS Controls)

Deliverable:

Surveillance audit plan and schedule
3-year ISMS roadmap for continuous improvement
Budget allocation for ongoing ISMS operations and surveillance audits

Phase 4 Deliverables Checklist

Certification body selected and contracted
Stage 1 audit completed with findings addressed
Stage 2 audit completed
All audit findings closed with verified corrective actions
ISO 27001:2022 certificate issued
Surveillance audit scheduled
Ongoing ISMS maintenance plan established

Phase 4 Success Metrics:

ISO 27001:2022 certification achieved within 24 months of project start
Zero major nonconformities in Stage 2 audit
< 5 minor nonconformities in Stage 2 audit
Certification maintained through first surveillance audit

Implementation Tools and Templates

Template 1: Risk Assessment Template

Risk Register Format (Excel/Google Sheets):

Risk ID	Asset	Threat	Vulnerability	Existing Controls	Likelihood (1-5)	Impact (1-5)	Inherent Risk	Risk Treatment	Additional Controls	Residual Likelihood	Residual Impact	Residual Risk	Risk Owner	Status
R-001	Student Information System	Ransomware	Unpatched vulnerabilities	Antivirus, firewall, backups	4	5	20 (Critical)	Mitigate	Implement EDR, MFA for admin access, patch mgmt process	2	5	10 (Medium)	Registrar	Closed
R-002	Financial data	Unauthorized access	Weak passwords	Password policy	3	4	12 (High)	Mitigate	Enforce MFA, access reviews quarterly	2	4	8 (Medium)	CFO	Open

Download: [Risk-Assessment-Template.xlsx]

Template 2: Access Request Form

Access Request Procedure:

ACCESS REQUEST FORM

Requestor Information:
Name: _______________________
Email: _______________________
Department: _______________________

Access Details:
System/Application: _______________________
Access Level Requested: [ ] Read-Only  [ ] Standard User  [ ] Elevated/Admin
Business Justification: _______________________________________________________
Duration (if temporary): From __________ To __________

Approval:
Manager/Supervisor Approval: _______________________ Date: __________
Information Asset Owner Approval: _______________________ Date: __________
(Required for Confidential/Restricted data access)

IT Implementation:
Implemented by: _______________________ Date: __________
Account Username: _______________________
Access granted per approval: [ ] Yes
Access Review Date: __________ (annual from grant date)

Notes:
_______________________________________________________________________

Template 3: Incident Report Form

SECURITY INCIDENT REPORT

Incident ID: __________ (auto-generated)
Reported Date/Time: __________
Reported By: Name: _____________ Email: _____________ Phone: _____________

Incident Classification:
[ ] Malware/Ransomware
[ ] Unauthorized Access
[ ] Data Breach/Loss
[ ] Phishing/Social Engineering
[ ] Denial of Service
[ ] Physical Security Breach
[ ] Policy Violation
[ ] Other: _____________

Incident Description:
What happened? _________________________________________________________________
When did it occur? _________________________________________________________________
What systems/data affected? _________________________________________________________________
How was it discovered? _________________________________________________________________

Initial Severity Assessment:
[ ] Critical  [ ] High  [ ] Medium  [ ] Low

Incident Response:
Incident Commander Assigned: _____________
Response Team Activated: [ ] Yes  [ ] No
Containment Actions Taken: _________________________________________________________________

--- For IR Team Use ---
Root Cause: _________________________________________________________________
Impact Assessment: _________________________________________________________________
Lessons Learned: _________________________________________________________________
Corrective Actions: _________________________________________________________________
Incident Closed Date: __________ Closed By: _____________

Template 4: Vendor Security Assessment

Vendor Risk Questionnaire (Excerpt - Full version 40-60 questions):

VENDOR INFORMATION SECURITY ASSESSMENT

Vendor Name: _______________________
Contact: _______________________
Service Description: _______________________
Data Classification Handled: [ ] Public  [ ] Internal  [ ] Confidential  [ ] Restricted

SECTION 1: Information Security Program
1.1 Does your organization have a formal information security policy?  [ ] Yes  [ ] No
1.2 Is your information security program based on a recognized framework (ISO 27001, NIST, SOC 2)?  [ ] Yes  [ ] No
    If yes, specify: _______________________
1.3 Do you conduct annual risk assessments?  [ ] Yes  [ ] No
1.4 Do you have a dedicated security team or CISO?  [ ] Yes  [ ] No

SECTION 2: Data Protection
2.1 Will you store, process, or transmit our institutional data?  [ ] Yes  [ ] No
2.2 Where is data stored geographically? _______________________
2.3 Is data encrypted at rest?  [ ] Yes  [ ] No  If yes, encryption method: _______________________
2.4 Is data encrypted in transit?  [ ] Yes  [ ] No  If yes, protocol: _______________________
2.5 Can you provide a Data Processing Agreement (DPA)?  [ ] Yes  [ ] No

SECTION 3: Access Control
3.1 Do you enforce multi-factor authentication for administrative access?  [ ] Yes  [ ] No
3.2 Do you conduct periodic access reviews?  [ ] Yes  [ ] No  Frequency: _______
3.3 Do you conduct background checks on employees with data access?  [ ] Yes  [ ] No

SECTION 4: Incident Response
4.1 Do you have an incident response plan?  [ ] Yes  [ ] No
4.2 Will you notify us of security incidents involving our data?  [ ] Yes  [ ] No
4.3 Notification timeline: Within _____ hours of discovery

SECTION 5: Compliance and Audits
5.1 Do you undergo independent security audits?  [ ] Yes  [ ] No
5.2 Can you provide SOC 2 Type II report or ISO 27001 certificate?  [ ] Yes  [ ] No
5.3 Do you comply with applicable regulations (FERPA, GDPR, HIPAA)?  [ ] Yes  [ ] No

Risk Rating:
[ ] Low Risk - Approved    [ ] Medium Risk - Approved with conditions    [ ] High Risk - Require remediation or reject

Assessed by: _______________________ Date: __________
Approved by (Information Security Manager): _______________________ Date: __________

Template 5: Training Completion Tracker

Security Awareness Training Dashboard (Excel/Google Sheets):

Department	Total Employees	Training Required	Completed	Completion %	Outstanding	Due Date
IT Services	25	25	25	100%	0	2025-12-31
Academic Affairs	150	150	142	95%	8	2025-12-31
Student Services	45	45	40	89%	5	2025-12-31
Finance	30	30	28	93%	2	2025-12-31
Total	250	250	235	94%	15

Track monthly and send reminders to departments below 90% compliance.

Educational Institution-Specific Adaptations

Adaptation 1: FERPA Integration with ISMS

FERPA Alignment with ISO 27001 Controls:

FERPA Requirement	ISO 27001 Control	Implementation in ISMS
Limit access to education records to school officials with legitimate educational interest	A.5.15 Access control	Role-based access control to SIS, access reviews to verify legitimate need
Obtain consent before disclosing personally identifiable information	A.5.34 Privacy and protection of PII	Data classification policy defines student records as Confidential, sharing requires consent workflow (except FERPA exceptions)
Provide parents/students right to inspect and review education records	A.5.33 Protection of records	SIS functionality for student self-service record access, registrar process for record requests
Maintain log of disclosures	A.8.15 Logging	Access logs for SIS, disclosure tracking in registrar system
Annual notification of FERPA rights	A.6.3 Information security awareness	Include FERPA rights in student orientation materials, annual privacy notice

ISMS Process Integration:

Risk assessment includes FERPA violation as high-impact risk scenario
Incident response plan includes FERPA breach notification procedures (notify Department of Education within required timeline)
Training includes FERPA module for all staff with student record access
Data Processing Agreements with vendors include FERPA compliance requirements

Adaptation 2: Research Data Security

Sensitive Research Data Categories:

Research Type	Regulatory Framework	ISO 27001 Control Enhancements
Human Subjects Research	IRB requirements, HIPAA (if health data)	Informed consent process includes data security disclosure, encryption required for all human subjects data, separate network segment for HIPAA research
Export-Controlled Research	EAR, ITAR	Physical and logical access controls for export-controlled data, deemed export training, separate enclave with restricted access
CUI (Controlled Unclassified Information)	NIST SP 800-171	Align ISMS controls with NIST 800-171 requirements (110 controls), obtain CMMC certification if DoD-funded
Intellectual Property / Proprietary	Contractual obligations	NDA requirements for research team, secure collaboration platforms for industry-sponsored research

Research IT Governance Model:

Baseline security requirements apply to all research (ISMS scope)
Enhanced security requirements for sensitive research (overlay controls)
Researcher responsibility for data classification and determining appropriate controls (in consultation with IT Security)
IT Security consulting service for researchers to assess and implement appropriate controls

Adaptation 3: Student-Involved Security Operations

Leveraging Student Workers:

Educational institutions can involve students in ISMS operations (workforce development + resource efficiency):

ISMS Function	Student Involvement	Safeguards
Security Monitoring (SOC)	Student workers monitor SIEM alerts (Tier 1), escalate to staff	Students limited to read-only access, no sensitive investigation data, supervised by full-time staff
Vulnerability Scanning	Student workers run scans, generate reports	Staff review findings, students don’t have remediation access
Security Awareness Content	Student interns create awareness videos, posters, campaigns	Staff approve all content before publication
Phishing Simulations	Student workers design and send phishing tests	Staff oversight, no access to click-through data with personal identifiers
Documentation	Student technical writers help document procedures	Staff review and approve all documentation

Benefits:

Real-world experience for cybersecurity students
Cost-effective resource augmentation
Student perspective on awareness messaging

Risks to Manage:

Student turnover (semester/annual)
Limited experience requires close supervision
Potential access to sensitive data must be carefully controlled

Budget Planning

Estimated Costs for ISO 27001 Implementation (Medium-Sized College - 3,000 students, 300 staff)

Phase 1: Foundation (Months 1-4)

Item	Cost Range	Notes
External consultant (gap analysis, planning)	₱840,000-1.4M	2-3 weeks engagement
ISMS project manager (internal staff allocation)	₱1.68M-2.24M	0.5 FTE for 4 months
Steering committee time	₱0 (existing staff)	Opportunity cost
Phase 1 Total	₱2.52M-3.64M

Phase 2: Control Implementation (Months 5-14)

Item	Cost Range	Notes
ISMS project manager	₱5.6M-7.28M	1.0 FTE for 10 months
Technical implementation staff	₱2.8M-4.48M	0.5-1.0 FTE, may be absorbed by existing IT staff
MFA solution	₱280-840/user/year = ₱252,000-756,000	900 users (students + staff)
PAM solution	₱840,000-2.24M/year	Based on privileged account count
EDR solution	₱2,240-3,360/endpoint/year = ₱672,000-1.01M	300 endpoints (staff devices)
SIEM solution	₱1.12M-2.8M/year	Varies widely (open-source to commercial)
Vulnerability scanning	₱280,000-840,000/year	Commercial scanner
Security awareness training platform	₱168,000-448,000/year	LMS-integrated or standalone
Encryption (BitLocker/FileVault)	₱0	Included in OS, MDM may have cost
External consultant (technical guidance)	₱560,000-1.12M	As-needed support
Phase 2 Total	₱13.7M-22.1M	(10-month period)

Phase 3: Documentation and Internal Audit (Months 15-18)

Item	Cost Range	Notes
ISMS project manager	₱2.24M-2.91M	1.0 FTE for 4 months
Technical writer (documentation)	₱280,000-560,000	Contract or internal
Internal audit (external auditors)	₱448,000-840,000	1-2 week engagement
Phase 3 Total	₱2.97M-4.31M

Phase 4: Certification Audit (Months 19-24)

Item	Cost Range	Notes
ISMS project manager	₱1.68M-2.24M	0.5 FTE for 6 months
Stage 1 audit	₱448,000-840,000	2 days
Stage 2 audit	₱840,000-1.68M	3-4 days
Certification body fees (registration, certificate)	₱112,000-280,000	Annual certification fee
Phase 4 Total	₱3.08M-5.04M

TOTAL 18-24 Month Implementation Cost: ₱22.3M-35.1M

Annual Ongoing Costs (Post-Certification):

Item	Cost Range
ISMS manager (internal staff)	₱4.48M-6.72M (1.0 FTE or added responsibility)
Tooling (MFA, PAM, EDR, SIEM, vuln scanning, training)	₱5.04M-8.68M/year
Surveillance audit (annual)	₱448,000-672,000
Recertification audit (every 3 years)	₱840,000-1.68M (amortized ~₱280,000-560,000/year)
Annual Ongoing Total	₱10.25M-16.6M/year

Budget Strategies for Resource-Constrained Institutions:

Phased approach: Implement critical controls first, expand over time
Open-source tools: Leverage open-source SIEM (Wazuh), vulnerability scanner (OpenVAS) to reduce costs
Education discounts: Many vendors offer free or heavily discounted licensing for educational institutions (Microsoft, Google, many security vendors)
Shared services: Regional consortia or system-wide security services (shared SOC, shared compliance staff)
Grant funding: Seek grants for cybersecurity improvements (NSF, DHS, state higher ed technology grants)

Success Factors and Common Pitfalls

Critical Success Factors for Educational Institutions

Executive Leadership Commitment
- Visible support from President/Provost level
- Budget allocated and protected
- Leadership willing to make hard decisions (enforce policies, accept some inconvenience)
Faculty Engagement
- Involve faculty early in policy development
- Frame security as protecting academic mission, not restricting it
- Faculty champions on steering committee
- Respect shared governance culture
Realistic Scoping
- Start with achievable scope (critical systems)
- Expand over time rather than over-promising initially
- Recognize resource constraints and plan accordingly
Integration with Existing Processes
- Align with institutional planning cycles (budget, academic calendar)
- Integrate security into existing IT processes (change management, project planning)
- Don’t create parallel bureaucracy
Communication and Training
- Consistent messaging about “why” (protect students, protect research, regulatory compliance)
- Invest in training - technical and awareness
- Make it easy to comply (good UX for security tools)
Adequate Resources
- Dedicated ISMS project manager (not “in addition to other duties”)
- Technical staff time for implementation
- Budget for tooling and consulting

Common Pitfalls and How to Avoid Them

Pitfall	How to Avoid
”Checkbox compliance” mentality	Focus on risk reduction and mission protection, not just passing audit. Use ISMS to drive real security improvements.
Underestimating timeline	ISO 27001 implementation takes 18-24 months. Don’t rush; it’s a marathon, not a sprint.
Documentation without implementation	Ensure policies are followed in practice. Audit your own compliance regularly.
Security vs. Usability tradeoff handled poorly	Involve users in design of security controls. Test usability. Iterate.
Ignoring cultural fit	Academic culture values autonomy and collaboration. Design controls that respect this (e.g., conditional access based on risk, not blanket restrictions).
Scope creep	Resist pressure to expand scope mid-implementation. Complete initial scope, then expand in next cycle.
Losing momentum post-certification	ISMS is not “done” at certification. Plan for ongoing operations, continuous improvement.
Treating ISMS as IT project only	ISMS is institutional project. Involve all stakeholders (academic affairs, finance, HR, legal, student services).

Conclusion and Next Steps

ISO 27001 implementation in educational institutions is a substantial but achievable undertaking. This guide provides a roadmap from initial planning through certification and ongoing operations, adapted to the unique context of higher education.

Key Takeaways:

ISO 27001 is a framework, not a checklist: Adapt controls to your institutional context, risk profile, and resources
Risk-based approach: Focus on protecting what matters most - student data, research data, critical operations
Cultural alignment is critical: Work with academic culture, not against it
Implementation is iterative: Perfect is the enemy of good; implement baseline controls, then continuously improve
Certification is a milestone, not the destination: ISMS is a living program requiring ongoing commitment

Immediate Next Steps (First 30 Days):

Secure executive sponsor commitment
Allocate budget for 18-24 month implementation
Designate ISMS project manager (0.5-1.0 FTE)
Form steering committee with diverse representation
Engage external consultant for gap analysis (optional but recommended)
Define initial ISMS scope
Develop detailed project plan based on this guide

Additional Resources:

ISO Standards: Purchase ISO/IEC 27001:2022 and ISO/IEC 27002:2022 from ISO.org or national standards body
Educause Resources: Educause HEISC (Higher Education Information Security Council) provides education-specific security guidance
NIST Resources: NIST Cybersecurity Framework, NIST SP 800-171 (if handling CUI), freely available
Companion Article: “Creating an Implementation Guide for ISO 27001 in Educational Institutions: A Research Synthesis” for theoretical background and literature review

Continuous Improvement Opportunities Beyond Certification:

Integration with COBIT for IT governance alignment
Adoption of NIST CSF or CIS Controls for enhanced technical security
Expansion of ISMS scope to cover additional systems or campuses
Maturity assessment and roadmap to advanced security capabilities
Participation in information sharing communities (REN-ISAC for education)

About This Guide

This implementation guide was developed to provide practical, actionable guidance for educational institutions pursuing ISO 27001:2022 certification. It complements the research article “Creating an Implementation Guide for ISO 27001 in Educational Institutions: A Research Synthesis,” which provides the theoretical foundation and literature review supporting the recommendations in this guide.

For questions, updates, or to share your implementation experiences, please contribute to the ongoing discussion of information security in higher education.

Last Updated: November 2025 Version: 1.0 Recommended Review Cycle: Annual updates to reflect changes in ISO 27001 standard, educational technology landscape, and threat environment

This guide is provided for educational purposes. Organizations should consult with qualified information security professionals and legal counsel when implementing an Information Security Management System and pursuing ISO 27001 certification.