可用性の原則と基準の表の基準1.0、1.1

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準の表の基準1.0、1.1です。
Availability Principle and Criteria Table
可用性の原則と基準の表

• .20 The system is available for operation and use as committed or agreed.
• .20 システムは約束または合意した操作と利用が可能である。

Criteria 1.0
Policies: The entity defines and documents its policies for the availability of its system.
基準 1.0原則：システムの可用性のポリシーは定義されと記述されている。

Criteria 1.1
The entity’s system availability and related security policies are established and periodically reviewed and approved by a designated individual or group.
基準 1.1
システムの可用性と関連するセキュリティポリシーは確立され、定期的に確認され、指名された個人またはグループにより 承認される。

Illustrative Controls
The entity’s documented systems development and acquisition process includes procedures to identify and document authorized users of the system and their availability and related security requirements.
User requirements are documented in service-level agreements or other documents.
Management reviews the entity’s availability and related security policies annually. Proposed changes are submitted as needed for approval by the information technology (IT) standards committee, which includes representation from the customer service department.
統制の実例
ドキュメント化されたシステム 開発と獲得過程は、認証の手順と承認されたユーザーのドキュメントと可用性および関連するセキュリティの要求を含む。
ユーザーの要求はサービスレベル合意や他 のドキュメントに文書化される。
経営者は可用性と関連するセキュリティポリシーを毎年確認する。
変更提案は顧客サービス部署の代表を含む情報技術（IT）標準委員会に よる要承認事項として提出される。

可用性の原則と基準

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準です。

Availability Principle and Criteria
可用性の原則と基準

• .18 The availability principle refers to the accessibility to the system, products, or services as advertised or committed by contract, service-level, or other agreements. It should be noted that this principle does not, in itself, set a minimum acceptable performance level for system availability. The minimum performance level is established through commitments made or by mutual agreement (contract) between the parties.
• .18 可用性の原則は、契約やサービスレベル他の合意により宣伝または約束された、システムや製品またはサービスへの到達性に言及する。この原則はそれ自身では システム可用性の最小許容可能なパフォーマンスレベルを設定しないことに注意すべきである。最小許容可能なパフォーマンスレベルは約束作りを通じて、または、当事者間の相互の合意（契約）によって確立されます。

• .19 Although there is a connection between system availability, system functionality, and system usability, the availability principle does not address system functionality (the specific functions a system performs) and system usability (the ability of users to apply system functions to specific tasks or problems). It does address system availability, which relates to whether the system is accessible for processing, monitoring, and maintenance.
• .19 システムの可用性とシステムの機能性、そしてシステムの有用性の間に関係があるとしても、可用性の原則はシステムの機能性（システムの特定の機能）とシス テムの有用性（特定のタスクや問題へのシステムの機能に適応するユーザーの能力）を扱わない。システムが処理、監視、そして保守に関連し到達可能であるか 否かはシステムの可用性を説明しない。

基準 4.3

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.3です。

Criteria 4.3
Environmental and technological changes are monitored and their effect on system security is assessed on a timely basis.
基準 4.3
環境と技術変更は監視さ れ、それらがシステムセキュリティにおよぼす影響は適時に見積もられる。

Illustrative Controls
Senior management, as part of its annual IT planning process, considers developments in technology and the impact of applicable laws or regulations on the entity’s security policies.
The entity’s IT security group monitors the security impact of emerging technologies.
Users are proactively invited to contribute to initiatives to improve system security through the use of new technologies.
統制の実例
上級管理職は、年度IT計画の 策定プロセスの一部として、開発技術とセキュリティポリシーに適用される法令・規定の影響検討する。
ITセキュリティグループは技術の出現によるセキュリティへの影響を監 視する。
ユーザー は率先的に、新技術の利用を通じてシステムセキュリティの改善を主導し貢献することに招かれる。

基準 4.2

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.2です。

Criteria 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system security policies.
基準 4.2
システムセキュリティポリシーに則り目的を達成するための継続能力に対する潜在的な障害を識別し対処するプロセスがあ る。

Illustrative Controls
Logs are analyzed to identify trends that may have a potential impact on the entity’s ability to achieve its system security objectives.
Monthly IT staff meetings are held to address system security concerns and trends; findings are discussed at quarterly management meetings.
統制の実例
記録はシステムセキュリティ の目的を達成する能力に対する潜在的な衝撃の傾向を識別するために分析される。
月例ITスタッフミーティングはシステムセキュリティ懸念事項と傾向に対処するために開催さ れる。

基準 4.0、4.1

引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.0、4.1です。

Criteria 4.0
Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies.
基準 4.0
監 視：システムを監視し、定義されたシステムセキュリティポリシーの遵守を維持するためのアクションをとる。

Criteria 4.1
The entity’s system security is periodically reviewed and compared with the defined system security policies.
基準 4.1
システムセキュリティは定期的に確認され、定義されたシステムセキュリティポリシーと比較される。

Illustrative Controls
The information security team monitors the system and assesses the system vulnerabilities using proprietary and other tools. Potential risk is evaluated and compared to service-level agreements and other obligations of the entity. Remediation plans are proposed and implementation is monitored.
The entity contracts with third parties to conduct periodic security reviews and vulnerability assessments. The internal audit function conducts system security reviews as part of its annual audit plan.
Results and recommendations for improvement are reported to management.
統制の実例
情報セキュリティチームはシステムを監視し、所有権や他のツールを使いシステムの脆弱性を見積もる。潜在的なリスクは評価され、サービスレベル合意と他の義務と比較される。修復計画が提案され、実装が監視される。
定期的なセキュリティ確認と脆弱性見積について第三者と契約する。内部監査機能はシステムセキュリティ確認を年度の監査 計画の一環として指揮する。
結果と改善の提言は経営者へ報告される。

基準 3.12

引き続 き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.12です。
Criteria 3.12
Procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval).
基準 3.12
緊急変更が文書化され承認されることを供給する手順が存在する。（事後の承認を含む）

Illustrative Controls
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.
Emergency changes that require deviations from standard procedures are logged and reviewed by IT management daily and reported to the affected line-of-business manager. Permanent corrective measures follow the entity’s change management process, including line-of-business approvals.
統制の実例
変更要求、システム保守、そしてサプライヤーのメンテナンスは標準化され、文書化された変更管理手順に従う。変更は分 類され、優先度により順位付けされ、緊急事項を取り扱う手順がある。
変更要求はそれらの状況が継続的に知らされる。
標準的な手順から逸脱する必要のある緊急 変更は記録されIT管理者により毎日確認され、影響のあるビジネスラインの管理者へ報告される。常設是正措置は、ビジネスラインの承認を含む、変更管理プ ロセスに従う。

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