公認内部監査人(CIA)tunetterのブログです。 内部監査の試行錯誤を記録していきます。

にほんブログ村 経営ブログ 経営学へ
いま何位?

2010年4月13日火曜日

基準 3.11

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.11です。
Criteria 3.11
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.

基準 3.11
システムへの変更の承認、テストそ して文書化のみを供給するための手順が存在する

Illustrative Controls
Senior management has implemented a division of roles and responsibilities that segregates incompatible functions.
The entity’s documented systems development methodology describes the change initiation, software development and maintenance, and approval processes, as well as the standards and controls that are embedded in the processes. These include programming, documentation, and testing standards.
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Changes to system infrastructure and software are developed and tested in a separate development or test environment before implementation into production.
As part of the change control policies and procedures, there is a “promotion” process (for example, from “test” to “staging” to “production”).
Promotion to production requires the approval of the business owner who sponsored the change and the manager of computer operations.
When changes are made to key systems components, there is a "backout" plan developed for use in the event of major interruption(s).

統制の実例
上級管理職は互換性のない機能 を分離する職務の分離と責任を実装する。
文書化されたシステム開発手法には、プロセスに埋め込まれた標準と統制と同様に、変更の開始、ソフトウェア開発と保守、 そして承認プロセスが記載される。これらはプログラミング文書とテストの基準も含む。
変更、保守そしてサプライヤーの保守への要求は標準化され、文書化された変更管理手続 に従う。変更は優先度により分類・順位付けされる。そして、緊急事項を取扱う手順がある。
変更要求者は自らの要求の状況について情報が与え続けられる。
システムインフラとソフトウェアの変更 は分離された開発またはテスト環境にて製品への実装前に開発されテストされる。
変更統制ポリシーと手順の一部として、「促進」プロセス(例:テストから提供、製作へ)があ る。
製品の促進は 変更を提供するビジネスオーナーとコンピューター操作の管理者の承認を要する。変更が主要システムコンポーネントに行われる時は、大規模中断のために開発 された「復元」計画が存在する。

0 件のコメント:

コメントを投稿