mirror of
https://github.com/strongdm/comply
synced 2024-07-02 23:14:22 +00:00
Merge branch 'master' of github.com:strongdm/comply
This commit is contained in:
Manisha Singh
commit
5e82aa0cfe
5
Makefile
5
Makefile
|
|
@ -107,9 +107,14 @@ release: release-env dist release-deps
|
|||
@echo "Update homebrew formula with the following: "
|
||||
@echo "version $(VERSION)"
|
||||
@curl -L https://github.com/strongdm/comply/archive/$(VERSION).tar.gz |shasum -a 256
|
||||
|
||||
patch-release: release-env push-assets patch release
|
||||
$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
|
||||
curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
|
||||
|
||||
minor-release: release-env push-assets minor release
|
||||
$(eval VERSION := $(shell git describe --tags --always --dirty="-dev"))
|
||||
curl -X POST --data-urlencode 'payload={"channel": "#release", "username": "release", "text": "comply $(VERSION) released", "icon_emoji": ":shipit:"}' https://hooks.slack.com/services/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
|
||||
|
||||
patch: clean gitsem
|
||||
gitsem -m "increment patch for release (via Makefile)" patch
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -8,4 +8,111 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. This application security policy defines the security framework and requirements for applications, notably web applications, within the organization’s production environment.
|
||||
|
||||
a. This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
|
||||
|
||||
a. This policy applies to all applications within the organization’ production environment, as well as administrators and users of these applications. This typically includes employees and contractors.
|
||||
|
||||
# Background
|
||||
|
||||
a. Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
|
||||
|
||||
a. In addition to scanning guidance, this policy also defines technical requirements and procedures to ensure that applications are properly hardened in accordance with security best practices.
|
||||
|
||||
# References
|
||||
|
||||
a. Data Classification Policy
|
||||
|
||||
a. OWASP Risk Rating Methodology
|
||||
|
||||
a. OWASP Testing Guide
|
||||
|
||||
a. OWASP Top Ten Project
|
||||
|
||||
# Policy
|
||||
|
||||
a. The organization must ensure that all applications it develops and/or acquires are securely configured and managed.
|
||||
|
||||
a. The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
|
||||
|
||||
i. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (a)).
|
||||
|
||||
i. If the application processes confidential information, a confidential record banner must be prominently displayed which highlights the type of confidential data being accessed (e.g., personally-identifiable information (PII), protected health information (PHI), etc.)
|
||||
|
||||
i. Sensitive data, especially data specifically restricted by law or policy (e.g., social security numbers, passwords, and credit card data) should not be displayed in plaintext.
|
||||
|
||||
i. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to cross-site scripting, buffer overflow errors, and injection flaws.
|
||||
|
||||
i. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, impair security mechanisms, or crash the system.
|
||||
|
||||
i. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
|
||||
|
||||
i. Ensure that applications encrypt data at rest and in transit.
|
||||
|
||||
i. Implement application logging to the extent practical. Retain logs of all users and access events for at least 14 days.
|
||||
|
||||
i. Qualified peers conduct security reviews of code for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
|
||||
|
||||
i. Implement a change management process for changes to existing software applications.
|
||||
|
||||
i. Standard configuration of the application must be documented.
|
||||
|
||||
i. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
|
||||
|
||||
i. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
|
||||
|
||||
i. During development and testing, applications must not have access to live data.
|
||||
|
||||
a. Where applications are acquired from a third party, such as a vendor:
|
||||
|
||||
i. Only applications that are supported by an approved vendor shall be procured and used.
|
||||
|
||||
i. Full support contracts must be arranged with the application vendor for full life-cycle support.
|
||||
|
||||
i. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
|
||||
|
||||
i. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible.
|
||||
|
||||
i. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
|
||||
|
||||
a. Web applications must be assessed according to the following criteria:
|
||||
|
||||
i. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
|
||||
|
||||
i. Third-party or acquired applications must have a full assessment prior to deployment.
|
||||
|
||||
i. Software releases must have an appropriate assessment, as determined by the organization’s information security manager, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
|
||||
|
||||
i. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
|
||||
|
||||
a. Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (b)):
|
||||
|
||||
i. High - issues categorized as high risk must be fixed immediately, otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
|
||||
|
||||
i. Medium - issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
|
||||
|
||||
i. Low - issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
|
||||
|
||||
a. Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
|
||||
|
||||
a. The following security assessment types may be leveraged to perform an application security assessment:
|
||||
|
||||
i. Full - comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (c)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
|
||||
|
||||
i. Quick - consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (d)).
|
||||
|
||||
i. Targeted - verifies vulnerability remediation changes or new application functionality.
|
||||
|
||||
i. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (c)).
|
||||
|
||||
i. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (d)).
|
||||
|
||||
i. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (e)).
|
||||
|
||||
i. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (f)).
|
||||
|
||||
i. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (g)).
|
||||
|
||||
|
|
|
|||
|
|
@ -8,4 +8,61 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
# Purpose and Scope
|
||||
|
||||
a. The purpose of this policy is to define the procedures to assess and treat information security risks within the organization, and to define the acceptable level of risk overall.
|
||||
|
||||
a. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all information systems which are used within the organization or which could have an impact on the organization’s information security.
|
||||
|
||||
a. This policy applies to all management and employees that take part in the organization’s risk assessments. This policy must be made readily available to all whom it applies to.
|
||||
|
||||
# Background
|
||||
|
||||
a. This policy defines a step-by-step process for conducting risk assessments, as well as to treat identified risks from an information security perspective. This policy also describes how to prepare the Risk Assessment Report required as part of the risk assessment process.
|
||||
|
||||
a. When conducting a risk assessment, the organization must identify all organizational information systems . It must then identify all threats and vulnerabilities having to do with such systems , and rate the severity of such threats and vulnerabilities according to a predefined rating scale. Asset and risk owners must be defined for each risk item.
|
||||
|
||||
a. Once the risk assessment is completed, the organization shall determine how to manage risks where the overall assessed risk rating is deemed as too high. This management is known as risk treatment. Risk treatment options include but are not limited to applying security controls, outsourcing risk, accepting risk, or discontinuing the activity associated with the risk.
|
||||
|
||||
a. A penetration test must be performed by a third party to verify the accuracy of the risk assessment and effectiveness of deployed risk treatments.
|
||||
|
||||
# Procedure To Execute Risk Assessment Report
|
||||
|
||||
a. Confirms that the entire risk assessment and risk treatment process has been carried out according to the Risk Assessment Policy.
|
||||
|
||||
a. The purpose of the risk assessment was to identify all information systems their vulnerabilities, and threats that could exploit vulnerabilities. These parameters were further evaluated in order to establish the criticality of individual risks.
|
||||
|
||||
a. The purpose of the risk treatment was to define the systematic means of reducing or controlling the risks identified in the risk assessment.
|
||||
|
||||
a. All risk assessment and treatment activities were completed within the scope of the organization’s information security program.
|
||||
|
||||
a. The risk assessment was implemented in the period from [day/month/year] to [day/month/year]. The risk treatment was implemented from [day/month/year] to [day/month/year]. Final reports were prepared during [specify period].
|
||||
|
||||
a. The risk assessment and risk treatment process was managed by [person responsible for managing the risk assessment process] with expert assistance provided by [person or company responsible for assistance].
|
||||
|
||||
a. During the risk assessment, information was collected through questionnaires and interviews with responsible persons, namely the asset owners across organizational units.
|
||||
|
||||
a. The process was conducted as follows:
|
||||
|
||||
i. All information systems and their owners were identified.
|
||||
|
||||
i. Threats were identified for each asset, and corresponding vulnerabilities were identified for each threat.
|
||||
i. Risk owners were identified for each risk.
|
||||
|
||||
i. Consequences of the loss of confidentiality, integrity and availability were evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
|
||||
|
||||
i. The likelihood of risk occurrence (i.e. that the threat will exploit the vulnerability) was evaluated using a score from 0 to 2, with 0 being the lowest rating and 2 being the highest rating.
|
||||
|
||||
i. The level of risk was calculated by adding up the consequence and likelihood.
|
||||
|
||||
i. Risks with a score of 3 or 4 were determined to be unacceptable risks.
|
||||
|
||||
i. For each unacceptable risk, a risk treatment option was considered, and appropriate information security controls were selected.
|
||||
|
||||
i. After controls were applied, residual risks were assessed.
|
||||
|
||||
a. The following documents were used or generated during the implementation of risk assessment and risk treatment:
|
||||
|
||||
i. Risk Assessment Table (Appendix A): for each combination of systems , vulnerabilities and threats, this table shows the values for consequence and likelihood, and calculates the risk.
|
||||
|
||||
i. Risk Treatment Table (Appendix B): defines the options for risk treatment, selection of controls for each unacceptable risk, and the level of residual risk.
|
||||
|
|
@ -8,5 +8,144 @@ majorRevisions:
|
|||
- date: Jun 1 2018
|
||||
comment: Initial document
|
||||
---
|
||||
#Purpose and Scope
|
||||
|
||||
# Coming Soon
|
||||
a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
|
||||
|
||||
a. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
|
||||
|
||||
a. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.
|
||||
|
||||
# Background
|
||||
|
||||
a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
|
||||
|
||||
a. The following conditions must be met for this plan to be viable:
|
||||
|
||||
i. All equipment, software and data (or their backups/failovers) are available in some manner.
|
||||
|
||||
i. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
|
||||
|
||||
i. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan.
|
||||
|
||||
a. This plan does not cover the following types of incidents:
|
||||
|
||||
i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.
|
||||
|
||||
i. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Relocation*
|
||||
|
||||
i. If the organization’s primary work site is unavailable, an alternate work site shall be used by designated personnel. The organization’s alternate work site is located at [list the address of the alternate work site that the organization will use].
|
||||
|
||||
i. The personnel required to report to the alternate work site during a disaster includes [list the personnel titles responsible for reporting to the alternate work site].
|
||||
|
||||
a. *Critical Services, Key Tasks and, Service Level Agreements (SLAs)*
|
||||
|
||||
i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):
|
||||
|
||||
1. [list the critical services and technologies that must remain running during a disaster]
|
||||
|
||||
i. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:
|
||||
|
||||
1. [list of key tasks / SLAs that must be kept operational, with respective deadlines]
|
||||
|
||||
a. The organization’s Recovery Time Objective (RTO) is [set the maximum amount of time before critical processes must be restored, to include relocation and getting critical services/technologies back online]. Relocation and restoration of critical services and technologies must be completed within this time period.
|
||||
|
||||
a. *Notification of Plan Initiation*
|
||||
|
||||
i. The following personnel must be notified when this plan is initiated:
|
||||
|
||||
1. [list all personnel (including titles) that must be notified of plan initiation ]
|
||||
|
||||
i. [person responsible for notifications, including title] is responsible for notifying the personnel listed above.
|
||||
|
||||
a. *Plan Deactivation*
|
||||
|
||||
i. This plan must only be deactivated by [person or persons with authority to deactivate the plan, including job title].
|
||||
|
||||
i. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of [person or persons with authority to deactivate the plan, including job title].
|
||||
|
||||
i. The following personnel must be notified when this plan is deactivated:
|
||||
|
||||
1. [list all personnel (including titles) that must be notified of plan activation]
|
||||
|
||||
a. The organization must endeavor to restore its normal level of business operations as soon as possible.
|
||||
|
||||
a. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A.
|
||||
|
||||
a. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
|
||||
|
||||
i. [job title] must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.
|
||||
|
||||
i. [job title] is authorized to make urgent purchases of equipment and services up to [amount].
|
||||
|
||||
i. [job title] is authorized to communicate with clients.
|
||||
|
||||
i. [job title] is authorized to communicate with the public.
|
||||
|
||||
i. [job title] is authorized to communicate with public authorities such as state and local governments and law enforcement.
|
||||
|
||||
i. [job title] is authorized to cooperate with [name of supplier/outsourcing partner].
|
||||
|
||||
i. [add/modify/remove authorizations in this section as necessary]
|
||||
|
||||
a. Specific recovery steps for information systems infrastructure and services are provided in Appendix B.
|
||||
|
||||
\pagebreak
|
||||
|
||||
# Appendix A: Relevant Points of Contact
|
||||
|
||||
Internal Contacts
|
||||
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| Name | Job Title | Phone Number | Email Address |Alternate Contact|
|
||||
+==================+===================+==================+==================+=================+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
|
||||
External Contacts
|
||||
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| Name | Job Title | Phone Number | Email Address |Alternate Contact|
|
||||
+==================+===================+==================+==================+=================+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
|
||||
\pagebreak
|
||||
|
||||
# Appendix B: Recovery Steps for Information Systems Infrastructure & Services
|
||||
|
||||
Specific recovery procedures are described in detail below:
|
||||
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| Recovery Procedure | Person Responsible | Person(s) Notified When Complete |
|
||||
+============================+======================+====================================+
|
||||
| System to be recovered: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| task 1: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| task 2: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| System to be recovered: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| task 1: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
| task 2: | | |
|
||||
| | | |
|
||||
+----------------------------+----------------------+------------------------------------+
|
||||
|
|
@ -10,4 +10,79 @@ majorRevisions:
|
|||
comment: Initial document
|
||||
---
|
||||
|
||||
# Coming Soon
|
||||
#Appendices
|
||||
Appendix A: Retention Periods
|
||||
|
||||
# Purpose and Scope
|
||||
|
||||
a. This data retention policy defines the objectives and requirements for data retention within the organization.
|
||||
|
||||
a. This policy covers all data within the organization’s custody or control, irregardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
|
||||
|
||||
a. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information the organization owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.
|
||||
|
||||
# Background
|
||||
|
||||
a. The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.
|
||||
|
||||
a. The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.
|
||||
|
||||
\pagebreak
|
||||
|
||||
# Policy
|
||||
|
||||
a. *Information Retention*
|
||||
|
||||
i. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business.
|
||||
|
||||
i. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.
|
||||
|
||||
i. By default, the retention period of information shall be an active use period of exactly two years from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.
|
||||
|
||||
i. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.
|
||||
|
||||
i. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
|
||||
|
||||
i. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
|
||||
|
||||
i. Each employee and contractor affiliated with the company must return information in their possession or control to the organization upon separation and/or retirement.
|
||||
|
||||
i. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
|
||||
|
||||
a. *Information Archiving*
|
||||
|
||||
i. Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.
|
||||
|
||||
1. Physical (e.g., paper) records must be archived in secured storage (onsite or offsite) and clearly labeled in archive boxes naming the information owner.
|
||||
|
||||
1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.
|
||||
|
||||
i. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
|
||||
|
||||
1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.
|
||||
|
||||
1. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)
|
||||
|
||||
i. Information must be destroyed (defined below) at the end of the elapsed archiving period.
|
||||
|
||||
a. *Information Destruction*
|
||||
|
||||
i. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
|
||||
|
||||
i. The organization must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
|
||||
|
||||
a. Retention and archival periods for information that is created, processed, stored and used by the organization is defined in Appendix A, “Retention Periods.”
|
||||
|
||||
\pagebreak
|
||||
|
||||
# Appendix A: Retention Periods
|
||||
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| Information Type | Information Owner | Storage Location | Retention Period | Archival Period |
|
||||
+==================+===================+==================+==================+=================+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+------------------+-------------------+------------------+------------------+-----------------+
|
||||
Loading…
Reference in New Issue
Block a user