What is ISO 27001 Annex A 8.17 – Clock Synchronisation?
ISO 27001 Annex A 8.17 requires organizations to synchronize the clocks of information-processing systems with an approved time source.
The purpose is to ensure that systems record events using consistent and reliable timestamps.
This becomes particularly important when an organization needs to:
- Investigate a security incident
- Correlate events across multiple systems
- Analyze authentication activity
- Review application and database logs
- Investigate unauthorized access
- Establish the sequence of events
- Support forensic investigations
- Demonstrate what happened during an audit
Simple explanation:
If different systems show different times, it can become difficult to determine what actually happened and in what order.
Why is Clock Synchronisation Important?
Modern organizations rarely operate from one system.
A typical startup may use:
Laptop
↓
Identity Provider
↓
Cloud Infrastructure
↓
Application
↓
Database
↓
Firewall
↓
Security Monitoring Platform
Each system can generate its own logs.
If the clocks are significantly different, the timeline may become confusing.
Example
Suppose an attacker compromises an employee account.
The organization sees:
| System | Event | Timestamp |
|---|---|---|
| Identity Provider | Successful login | 10:05 |
| Cloud Platform | Privileged access | 09:57 |
| Application | Admin action | 10:03 |
| Database | Data query | 10:00 |
Which event happened first?
If the systems are not synchronized, investigators may have difficulty establishing the correct sequence.
With synchronized clocks:
10:00:01 → Login
10:00:14 → Privilege escalation
10:01:02 → Production access
10:02:15 → Database query
10:03:07 → Data export
The investigation becomes much easier.
Simple principle:
Accurate time creates a reliable timeline.
What Does ISO 27001 Annex A 8.17 Require?
The organization should identify information-processing systems where accurate time is important and ensure that their clocks are synchronized with an approved time source.
The organization should determine:
- Which systems require synchronization
- What time source should be used
- How synchronization is configured
- How synchronization failures are detected
- What level of accuracy is required
- Who is responsible
- How exceptions are handled
The implementation should be appropriate to the organization’s risks and technology environment.
What is Clock Synchronisation?
Clock synchronization is the process of ensuring that system clocks are aligned with a trusted or approved reference time.
Common technologies include:
- Network Time Protocol (NTP)
- Secure NTP implementations where appropriate
- Cloud-provider time services
- Enterprise time servers
- Domain controller time services
- GPS-based time sources in specialized environments
For most startups, standard network time synchronization is sufficient when properly configured.
What is NTP?
Network Time Protocol (NTP) is a protocol used to synchronize computer clocks over a network.
A simplified model is:
Approved Time Source
↓
NTP
↓
┌──────┼──────┐
↓ ↓ ↓
Cloud Server Endpoint
↓ ↓ ↓
Application / Security Logs
The systems periodically adjust their clocks so that timestamps remain aligned.
Organizations should use appropriately trusted time sources and configure systems according to their security requirements.
What is an Approved Time Source?
An organization should define which time sources are acceptable.
Examples may include:
- An organization’s internal time server
- A trusted external NTP service
- Cloud-provider time infrastructure
- Domain infrastructure
- A GPS-based reference clock
- Other formally approved sources
For a startup, the policy could simply define:
“Company-managed systems shall synchronize their system clocks with approved time sources.”
The exact technical implementation can then be documented.
Activities Required to Implement A.8.17
Step 1 – Identify Systems
Identify systems where accurate timestamps are important.
Examples:
- Servers
- Cloud infrastructure
- Databases
- Firewalls
- Network devices
- Identity platforms
- Endpoints
- Security appliances
- Applications
- Logging platforms
- SIEM platforms
Step 2 – Identify Critical Logging Systems
Pay particular attention to systems used for:
- Security monitoring
- Incident investigation
- Authentication
- Privileged access
- Financial transactions
- Customer activity
- Audit trails
If these systems have inconsistent timestamps, investigation becomes much harder.
Step 3 – Define an Approved Time Source
Document which time sources are approved.
For example:
Company Standard
↓
Approved NTP Source
↓
Cloud / Server / Endpoint Systems
For larger organizations, an internal hierarchy may be used:
Trusted Reference
↓
Internal Time Server
↓
Domain / Network Infrastructure
↓
Servers and Endpoints
Step 4 – Configure Synchronisation
Configure relevant systems to use the approved time source.
Depending on the environment, this may be handled through:
- Operating-system settings
- Cloud configuration
- Domain policies
- Network-device configuration
- Infrastructure-as-code
- Endpoint management
- Configuration-management tools
Step 5 – Verify Time Synchronisation
Do not assume synchronization is working because it was configured once.
Periodically verify:
- Time source
- Synchronization status
- Clock offset
- Configuration
- Synchronization failures
- System exceptions
Step 6 – Monitor Synchronisation Failures
Where appropriate, generate alerts when critical systems lose synchronization.
For example:
Server
↓
NTP synchronization failure
↓
Alert
↓
IT/Security review
↓
Corrective action
Step 7 – Handle Exceptions
Some systems may not be able to synchronize normally.
Examples could include:
- Legacy systems
- Isolated networks
- Specialized devices
- Third-party-managed systems
- Offline systems
Document:
- The affected system
- Why synchronization is not possible
- Associated risk
- Compensating controls
- Review requirements
Startup Example
Consider a SaaS company using:
- AWS
- GitHub
- Google Workspace
- PostgreSQL
- Cloud security monitoring
- Employee laptops
The organization experiences a suspected account compromise.
Security investigators review:
- Identity logs
- Cloud logs
- Application logs
- Database logs
- Endpoint logs
Initially, timestamps are inconsistent.
Identity Log 14:05
Application Log 14:01
Database Log 14:08
Cloud Log 13:58
Endpoint Log 14:03
The team has to determine whether the differences represent actual event ordering or simply clock differences.
After implementing appropriate synchronization:
14:01:03 → Authentication
14:01:12 → Cloud access
14:01:24 → Application access
14:01:41 → Database query
14:02:05 → Security alert
The event sequence becomes significantly easier to reconstruct.
Startup-Focused Quick Summary
A startup can address A.8.17 with a relatively simple approach.
Minimum practical approach:
- Identify critical systems
- Identify systems generating security logs
- Define approved time sources
- Configure synchronization
- Verify synchronization
- Monitor important synchronization failures
- Document exceptions
- Maintain evidence
Know the systems → Define the time source → Synchronize → Verify → Monitor → Correct
Clock Synchronisation and Security Logs
A.8.17 is particularly important because of its relationship with A.8.15 Logging.
Consider:
A.8.15
Logging
↓
Events receive timestamps
↓
A.8.17
Clock Synchronisation
↓
Timestamps are consistent
↓
A.8.16
Monitoring Activities
↓
Events can be correlated and investigated
These controls work together.
Clock Synchronisation and Incident Response
During an incident, investigators often construct a timeline.
For example:
09:42:10
Suspicious login
09:42:23
MFA challenge
09:43:02
New session created
09:44:15
Privilege change
09:45:08
Production access
09:46:31
Large data query
09:47:10
Security alert
If system clocks are inaccurate, the timeline may contain contradictions.
This can affect:
- Incident investigation
- Root-cause analysis
- Evidence collection
- Containment decisions
- Customer notifications
- Regulatory investigations
- Legal proceedings
Clock Synchronisation and Cloud Environments
Cloud environments often contain many systems distributed across:
- Availability zones
- Regions
- Virtual machines
- Containers
- Managed services
- Serverless functions
- Databases
- Security services
A startup should understand how time synchronization is handled across these components.
Questions to consider include:
- What time source does the platform use?
- Are virtual machines synchronized?
- Are containers inheriting host time?
- Are managed services providing timestamps?
- Can application logs use UTC consistently?
- Can timestamps be correlated across services?
UTC and Time Zones
A common operational practice is to use UTC for technical logs and system timestamps, particularly in globally distributed environments.
For example:
Application Log:
2026-09-27 04:15:32 UTC
Instead of having different systems record:
India: 09:45
US: 23:15
UK: 05:15
Using a consistent reference makes correlation easier.
The organization should define its approach and ensure teams understand how timestamps are interpreted.
Important: Time synchronization and time-zone display are related but different issues.
A system can have the correct clock but display the timestamp in a different time zone.
Application Logging Considerations
Developers should consider how applications generate timestamps.
For example, an application may:
- Use server time
- Use database time
- Use container time
- Generate timestamps in UTC
- Convert timestamps for users
The organization should ensure that security-relevant events have reliable timestamps and that their meaning is understood.
Database Time Synchronisation
Databases may be important sources of security and operational evidence.
Relevant systems may include:
- PostgreSQL
- MySQL
- Microsoft SQL Server
- Oracle
- MongoDB
Where database timestamps are used for security investigation or audit trails, the organization should ensure that the underlying infrastructure and database configuration support reliable timestamps.
Endpoints and Employee Devices
Employee laptops and desktops can also generate security events.
Examples:
- Login
- File access
- Security alert
- Malware detection
- Privilege escalation
- VPN connection
Managed endpoints should use appropriate time synchronization settings.
This becomes particularly important when endpoint events need to be correlated with:
- Identity logs
- Cloud activity
- VPN logs
- EDR alerts
- Application activity
What Happens if Time Synchronisation Fails?
Organizations should consider the potential impact.
For a critical system:
Time Sync Failure
↓
Incorrect timestamps
↓
Poor event correlation
↓
Investigation difficulty
↓
Potential security impact
The appropriate response may include:
- Alerting
- Investigation
- Correcting the system clock
- Reviewing affected logs
- Assessing whether evidence was impacted
- Documenting the issue
Audit Evidence
An ISO 27001 auditor may ask for evidence such as:
Governance
- Information security policy
- Clock synchronization standard
- Configuration standard
- Approved time-source list
Technical evidence
- NTP configuration
- Operating-system time configuration
- Cloud time configuration
- Domain policy
- Network-device configuration
- Synchronization status
Operational evidence
- Time synchronization checks
- Monitoring alerts
- Exception records
- Corrective-action records
Architecture evidence
- Network diagram
- Cloud architecture
- Infrastructure inventory
- System configuration records
A.8.17 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Have critical systems requiring accurate time been identified? | Asset inventory |
| Is an approved time source defined? | Standard/policy |
| Are critical systems synchronized? | Configuration evidence |
| Are servers synchronized? | Server configuration |
| Are network devices synchronized? | Network configuration |
| Are endpoints synchronized? | Endpoint-management evidence |
| Are cloud systems appropriately synchronized? | Cloud configuration |
| Are security monitoring systems synchronized? | Monitoring configuration |
| Are timestamps consistently interpreted? | Standard/documentation |
| Is UTC used where appropriate? | System/application standard |
| Are synchronization failures detected? | Alerts/monitoring |
| Are exceptions documented? | Exception register |
| Is synchronization periodically verified? | Review records |
| Are corrective actions recorded? | Tickets/evidence |
Common Mistakes
1. Assuming cloud systems automatically solve everything
Cloud platforms may provide time infrastructure, but the organization still needs to understand and manage its own configuration and application behaviour.
2. Synchronizing servers but ignoring endpoints
Endpoint events can be important during security investigations.
Relevant managed endpoints should also be considered.
3. Different systems using different time zones
This can make investigations unnecessarily difficult.
A consistent approach, often using UTC for technical logs, can simplify correlation.
4. No approved time source
If every administrator configures systems differently, the organization may end up with inconsistent time sources.
Define an approved approach.
5. No monitoring of synchronization failures
A system may stop synchronizing because of:
- Network problems
- Configuration changes
- Service failures
- Firewall rules
- DNS problems
- Time-source availability
Critical failures should be detected where appropriate.
6. Ignoring applications
Infrastructure may be synchronized correctly while an application generates timestamps incorrectly.
Application logging should therefore be considered.
7. Treating clock synchronization as only an IT issue
Accurate timestamps support:
- Security
- Incident response
- Auditability
- Operations
- Troubleshooting
- Forensics
It is therefore an information-security concern as well.
Practical Startup Implementation Model
A startup can use the following model:
1. Identify
Identify systems that generate security-relevant events.
2. Prioritize
Focus first on critical systems.
3. Define
Define approved time sources and the organization’s timestamp approach.
4. Configure
Configure synchronization.
5. Standardize
Where appropriate, standardize technical logs around a common time reference such as UTC.
6. Verify
Check synchronization status periodically.
7. Monitor
Detect important synchronization failures.
8. Correct
Fix synchronization issues promptly.
9. Document
Maintain evidence and exceptions.
10. Review
Review the approach as systems and architecture change.
Identify → Prioritize → Define → Configure → Standardize → Verify → Monitor → Correct → Document → Review
Minimum Viable Clock Synchronisation for a Startup
A startup should at minimum consider synchronization for:
- Production servers
- Cloud infrastructure
- Databases
- Identity systems
- Security monitoring systems
- Network devices
- Managed endpoints
- Critical applications
The organization should document:
Time source → Systems covered → Synchronization method → Owner → Verification method → Exception process
Example Clock Synchronisation Register
| System | Time Source | Method | Owner | Verification |
|---|---|---|---|---|
| Production Server | Approved NTP | NTP | IT | Periodic check |
| Database | Host/platform time | Platform configuration | Engineering | Configuration review |
| Cloud Infrastructure | Cloud-approved time source | Cloud configuration | Cloud Team | Automated/periodic |
| Network Device | Approved NTP | NTP | IT | Periodic check |
| Employee Laptop | Enterprise time service | Device management | IT | Management console |
| Security Platform | Platform time source | Provider configuration | Security | Configuration review |
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Critical information-processing systems shall maintain synchronized clocks |
| Standard | Approved time sources shall be used |
| Process | IT configures and periodically verifies synchronization |
| Technical Control | NTP / cloud time service / domain time |
| Evidence | Configuration, synchronization status and review records |
As with other ISO 27001 controls:
A policy does not prove implementation.
The organization should demonstrate:
Requirement → Configuration → Operation → Verification → Evidence
Relationship With Other ISO 27001 Controls
A.5.9 – Inventory of Information and Other Associated Assets
The organization needs to know which systems require time synchronization.
A.5.15 – Access Control
Authentication and access events depend on reliable timestamps.
A.5.16 – Identity Management
Identity lifecycle and authentication events need reliable event timing.
A.5.24 – Incident Management Planning and Preparation
Incident investigations depend on reliable event timelines.
A.5.25 – Assessment of Information Security Events
Security events from multiple sources may need to be correlated.
A.5.26 – Response to Information Security Incidents
Accurate timestamps support incident investigation and response.
A.5.28 – Collection of Evidence
Reliable timestamps can contribute to the integrity and usefulness of evidence.
A.8.15 – Logging
Logging records timestamps for security and operational events.
A.8.16 – Monitoring Activities
Monitoring may correlate events from multiple systems.
A.8.17 – Clock Synchronisation
Ensures relevant systems use a consistent and reliable time reference.
A.8.20 – Networks Security
Network devices and security controls generate events that may need to be correlated.
Useful Resources
MAE can provide supporting templates and practical implementation documents for this control.
Recommended documents
- [Insert Draft Document Link] – Clock Synchronisation Policy
- [Insert Draft Document Link] – Approved Time Sources Register
- [Insert Draft Document Link] – IT Configuration Standard
- [Insert Draft Document Link] – Time Synchronisation Verification Checklist
- [Insert Draft Document Link] – System Time Configuration Checklist
- [Insert Draft Document Link] – ISO 27001 A.8.17 Audit Checklist
Questions an Auditor May Ask
- What time source do your systems use?
- Which systems are required to synchronize their clocks?
- How did you determine the scope?
- Show me the time synchronization configuration for a critical server.
- How are cloud systems synchronized?
- How are employee endpoints synchronized?
- How do you handle network devices?
- Are security monitoring systems synchronized?
- Do your application logs use a consistent time reference?
- Do you use UTC for technical logs?
- How do you detect synchronization failures?
- What happens if a critical system loses synchronization?
- How frequently do you verify synchronization?
- Are there any systems that cannot synchronize?
- How are exceptions documented and managed?
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.17 may look like a simple technical configuration, but it can become extremely important during a security incident.
When investigators need to reconstruct an event, they often depend on timestamps from multiple systems.
If those timestamps cannot be trusted or compared reliably, the investigation becomes much more difficult.
For a startup, the key questions are:
Which systems generate security-relevant events?
What time source do they use?
Are their clocks synchronized?
Are timestamps consistently interpreted?
Do critical applications and security systems use reliable time?
How do we know synchronization is working?
What happens when synchronization fails?
A practical implementation can be summarized as:
Identify critical systems → Define an approved time source → Configure synchronization → Standardize timestamps → Verify → Monitor failures → Correct issues → Maintain evidence.
The key lesson for startups
A.8.15 Logging records the event.
A.8.16 Monitoring helps identify the event.
A.8.17 Clock Synchronisation helps establish when the event actually happened.
Together, these controls provide a stronger foundation for security monitoring, incident investigation, auditability, and forensic analysis.
That is the practical objective behind ISO 27001 Annex A 8.17 – Clock Synchronisation.