ASD ISM 2015 Central logging of non-internet network API data access
What it says
Network API calls that facilitate modification of data, or access to data not authorised for release into the public domain, but are not accessible over the internet, are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAll network API data changes not shared online must be logged centrally.
This control means that any time data is changed or accessed through a company's internal systems (not over the internet), these actions need to be recorded centrally. It matters because without keeping track of who accesses or changes important data, a business could be vulnerable to data tampering or breaches, possibly resulting in loss of trust, revenue, or legal issues.
Free. Save your status, tasks and notes.
Why it matters
Without central logging of internal (non-internet) API calls that access or modify non-public data, unauthorised access or changes may go undetected, harming integrity and compliance.
How to implement
The IT team should set up a logging system to capture all internal data access and changes through network APIs.
This can be done by configuring the server to automatically record details of every transaction involving data that isn't meant for public access.
Business owners should discuss with their IT team the types of sensitive data in their network that need monitoring.
They can identify critical data points by listing information that should not be public and ensuring they are logged effectively.
Office managers should ensure staff understand the importance of logging these internal activities.
This can be facilitated through training sessions that explain how improper access or changes could impact the business.
HR should help maintain awareness about data access policies by including logging practices in company policy manuals.
This involves updating the employee handbook to include why and how data access activities are logged.
System administrators should regularly review the central logs to spot unusual access patterns or unauthorised changes.
They should be trained to look for anomalies and report them promptly to prevent any potential issues.
Keep it running
Ensure internal (non-internet) APIs log centrally: caller identity, endpoint, timestamp and action (read/modify). Review logs and alert on unusual access to non-public data.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Recent central logs: Request access logs for internal systems over the past month. Look to see if all API accesses are recorded, noting time, user, and specific action taken.
Good evidence
Contains complete records without gaps, showing consistent monitoring.
- Check 2 of 5What an auditor asks for
Ask for
Logging policy documentation: Request the document outlining the logging process for internal data accesses.
Look at
Clear policies that define what should be logged and why.
Good evidence
Clearly lists all types of accesses that require logging and aligns with internal data security policies.
- Check 3 of 5What an auditor asks for
Ask for
To see staff training records related to data logging: Request training attendance sheets or materials from recent sessions.
Look at
Evidence of regular training sessions and participant lists.
Good evidence
Includes proof that staff involved with APIs understand logging importance.
- Check 4 of 5What an auditor asks for
Ask for
A demonstration of the logging system: Request a live demonstration of how logging is set up and monitored. Look to see the system in action and ensure it automatically captures all specified data transactions.
Good evidence
Shows a fully operational system that captures logs in real-time.
- Check 5 of 5What an auditor asks for
Ask for
A list of identified anomalies and response actions: Request records showing how anomalies in logs were addressed.
Look at
Reports that describe the finding, investigation, and resolution.
Good evidence
Shows documented follow-up on all identified issues, demonstrating an active management approach.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of activities and events, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.15.
ISM-2015 mandates central logging for specific data-affecting non-internet API calls. Annex A 8.15 requires logging of activities and significant events across systems, which encompasses API activities where applicable. Hence, ISM-2015 enforces a more specific aspect of the broader logging requirement found in Annex A 8.15, concentrating on internal API interactions.
This control supports A.8.16.
ISM-2015 mandates central logging of non-internet API calls that modify or access sensitive data. Annex A 8.16 supports this by necessitating network, system, and application monitoring to detect anomalies, which often relies on centrally logged data like API access records.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.