Source Program Management
Certification criterion
Source programs shall be managed so that only authorized users can access them, and, as a principle, shall not be stored in the operational environment.
Key checkpoints
- Are procedures established and implemented to control access to source programs by unauthorized persons?
- Are source programs stored safely in a location other than the operational environment, in preparation for emergencies such as failures?
- Is the change history of source programs managed?
Detailed explanation
※ This item is a relaxed certification criterion (Annex 7-2) under the special provisions for information security management system certification. The certification criterion and key checkpoints above are the official relaxed/adjusted text; the detailed explanation, related laws, evidence, and nonconformity examples below are the "ISMS-P Certification Criteria Guide" content for Annex 7 [2.8.5 Source Program Management], which belongs to the same control domain (under the relaxed criteria, this content applies within the scope of the certification criterion and key checkpoints above).
Procedures shall be established and implemented to control access to source programs by unauthorized persons.
- Establish procedures for access to and use of source programs
- Grant access rights so that only authorized developers and personnel can access, and block access by unauthorized persons
- Apply access control measures to the servers (such as configuration management servers) where source programs are stored
Source programs shall be stored safely in a location other than the operational environment, in preparation for emergencies such as failures.
- Keep backups of the latest source programs and previous source programs
- Store and manage them in a separate environment other than the operational environment
- Control access by unauthorized persons to source program backup copies
The change history of source programs shall be managed.
- Establish source program change procedures : approval and work procedures, version management methods, etc.
- Manage source program change history : dates of change/implementation/migration, reasons for change requests, responsible personnel, etc.
- Perform change control over system-related documents (such as design documents) resulting from source program changes
- Perform periodic reviews of source program change history and change control records, etc.
Related laws
No individual legal provision directly corresponding to this item is specified.
Evidence (examples)
- Operation status of configuration management systems such as SVN (list of persons with access rights, etc.)
- Source program change history
Nonconformity examples
- A case where no separate source program backup and configuration management system is in place, and previous versions of source code are stored on the operational server or on developers' PCs without approval and history management
- A case where a configuration management system is built and operated, but access restriction, access history, and change history for the configuration management system or the source code stored in it are not properly managed
- A case where internal regulations require source program version management through a configuration management system, but the latest version of the source program is stored only on a developer's PC and no separate backup is performed for it