Example of System Monitoring Policy

1 Policy  Statement

To ensure that organizational IT systems are not open to abuse, XXX reserves the right to monitor individual staff usage but only where authorized by senior HR staff and where, in the circumstances, it is fair and appropriate to do so. A range of monitoring activities needs to be established to ensure that the IT systems are operating efficiently and effectively. This includes the monitoring of information entering, leaving, or stored on organizational IT systems. Such monitoring is not, in general, person-specific, but the employee’s personal data may be accessed as part of this policy.

2 Purpose

This policy offers guidance regarding monitoring system use and related user activities. It is intended to guide and inform personnel and help them understand the importance of maintaining logs of all user activities on the system.

3 Scope

3.1 IT Assets

This policy applies to all organizational information systems and  Employees, Contractors, and Third Party Employees, who have access to IT assets and may be bound by contractual agreements.

3.2 Documentation

The System Monitoring Policy documentation shall consist of System Monitoring Policy, related procedures & guidelines.

3.3 Document Control

The System Monitoring Policy document and all other referenced documents shall be controlled. The version control shall be used to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

3.4 Records

Records being generated as part of the System Monitoring Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.5 Distribution and Maintenance

The System Monitoring Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the System Monitoring Policy document will be with the CISO and system administrators.

4 Privacy

The System Monitoring Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5 Responsibility

The CISO / designated personnel is responsible for proper implementation of the System Monitoring Policy.

6 Policy

Systems shall be monitored to ensure all information security events are recorded. The organization shall comply with all relevant legal requirements applicable to the monitoring and logging activities. System monitoring shall be used as a means to check the effectiveness of controls adopted and also to verify the conformance to the organizational access control and acceptable use policies.
System monitoring shall consider the following aspects:
a. compliance with regulatory and statutory obligations;
b. effective maintenance of IT systems;
c. prevention or detection of unauthorized use of, or other threats to the organizational IT systems, or criminal activities;
d. compliance with organizational policies and procedures; and
e. review of usage and staff training.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Anti-Spam and Unsolicited Commercial Email (UCE) Policy

1.  Purpose

This policy describes the permitted and prohibited uses of corporate email systems for bulk emailing. Its purpose is to:
1. protect organizational reputation,
2. preserve the effectiveness of email as a business communication medium,
3. prevent a potential breach of the US CAN-SPAM Act by employees, and
4. to generally encourage adherence to e-mail best practices.

2. Overview

The practice of sending unsolicited, commercial mass e-mails represents a potential threat to organizational reputation and maybe violation, which defines the quantity and characteristics of bulk commercial e-mails that may legally be sent. All communications with customers, prospects, and other professionals reflect XXX. In light of increasing antipathy to unsolicited email promotions of any kind, it is generally in the best interest of XXX to limit electronic mailings to legitimate communications with individuals who have indicated a willingness to receive them.

3. Scope

All individuals who use the e-mail systems and addresses to send bulk e-mails to customers, prospects, or other types of recipients.

3.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of the software installation Policy, and related procedures & guidelines. This Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

3.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any). This policy has full support from the executive steering committee and human resources. This policy is a living document and may be modified at any time by the IT manager, human resources, or the executive steering committee.

6 Policy

  • All mass emails must be approved by IT Manager.
  • Individuals may send mass emails for the purpose of marketing or sales of products, services, or programs only to:
    • Recipients who specifically consented to receive marketing or sales emails
    • Recipients who have not explicitly opted out of receiving marketing or sales emails
  • Mass emails sent from computers or email addresses may not:
    • o Contain false or misleading information in the subject line, headers, or email body
    • o In any way misrepresent or disguise the sender, point of origin, or the transmission path
  • Individuals may not send any emails to addresses that have been illicitly harvested, mined, or skimmed from one or more third-party Web sites. Employees may not build e-mail addresses or lists by guessing or using software to generate character strings that are likely to be associated with live email accounts.

Anti-spam restrictions also apply to other forms of electronic messaging:

  • Individuals may not post promotions or advertisements for products, services, or programs in newsgroups, message boards, chat rooms, or other online services in violation of the terms of participation of those online services.
  • Individuals may not post promotions or advertisements for products, services, or programs in newsgroups, message boards, chat rooms, or other online services that do not explicitly permit advertisements.
  • Individuals may not use vendors, software, or service providers or to circumvent the intent of this policy.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy. Violation of this policy may result in disciplinary action which may include performance sanctions; termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to restriction or suspension of email privileges, as well as civil and criminal prosecution.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Risk Management Policy

1 Policy Statement

To meet the enterprise business objectives and ensure continuity of its operations, XXX shall adopt and follow well-defined and time-tested plans and procedures, to ensure timely management of organizational risks. Employees are expected to cooperate fully with any Risk Assessment being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan. The policy and respective procedures, guidelines & forms shall be available to the CISO and members of senior management.

2 Definitions

Entity Any business unit, department, group, or a third party, internal or external to XXX, responsible for maintaining assets.

RiskThose factors that could affect confidentiality, availability, and integrity of XXX’s key information assets and systems. The Risk Assessment Team is responsible for ensuring the integrity, confidentiality, and availability of critical information and computing assets on networks while minimizing the impact of security procedures and policies upon business missions.

3 Purpose

The purpose of this policy is to identify areas of risk in a timely manner and manage them to ensure continuity of business processes. The execution, development, and implementation of remediation programs are the joint responsibility of the IT Infrastructure management team and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan.

4 Scope

4.1 IT Assets

This policy applies to the entire IT Infrastructure.

4.2 Documentation

The Policy documentation shall consist of Risk Management Policy, Risk Assessment and Treatment Procedure, and related guidelines.

4.3 Document Control

The Risk Management Policy document and all other referenced documents shall be controlled. The version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

4.4 Records

Records being generated as part of the Risk Management Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

4.5 Distribution and Maintenance

The Risk Management Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the Risk Management Policy document will be with the CISO and system administrators.

5 Privacy

The Risk Management Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

6 Responsibility

The CISO / designated personnel is responsible for proper implementation of the policy.

7 Policy

Risk Management Plan shall be drawn by the management which shall identify the people within XXX who will perform risk assessment operations. For this purpose, the events (or series of events) which cause disruption to business processes shall be identified. The risk assessment shall consider the probability and impact of such disruptions in terms of time, the scale of damage, and the recovery period. The risk assessment shall identify, quantify and prioritize risks against criteria and objectives relevant to the organization, including critical resources, impacts of disruptions, allowable outage times, and recovery priorities. Based on the results of the assessment, a business continuity strategy shall be outlined for XXX to determine the overall approach to business continuity. The execution, development, and implementation of remediation programs are the joint responsibility of the IT Infrastructure management team and the department responsible for the systems are being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Risk Assessment Team in the development of a remediation plan.

8 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Third Party Access Policy

1.  Purpose

This document describes the policy under which third-party persons or organizations connect to or access network resources on XXX networks for the purpose of transacting business related to XXX or other approved business transactions.

2. Scope

All connections and network resources access between third parties that require access to non-public resources fall under this policy, regardless of what technology is used for the connection. Connectivity to third parties such as the Internet Service Providers (ISPs) that provide Internet access for XXX or to the Public Switched Telephone Network does NOT fall under this policy.

2.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

2.2 Documentation

The documentation shall consist of the software installation Policy, and related procedures & guidelines. The Compliance Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

2.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

2.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

3. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

4. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any). This policy has full support from the executive steering committee and human resources. This policy is a living document and may be modified at any time by the IT manager, human resources, or the executive steering committee.

5 Policy

6.1 Pre-Requisites Security Review

All new extranet connectivity will go through a security review with the Office of the IT Manager. The reviews are to ensure that all access matches the business requirements in the best possible way and that the principle of least access is followed.

6.2 Third Party Connection Agreement

All new connection requests between third parties and XXX require that the third party and representatives agree to and sign the Third Party Agreement. This agreement must be signed by the IT Manager as well as a representative from the third party who is legally empowered to sign on behalf of the third party.  By signing this agreement the third party agrees to abide by all referenced policies. The signed document is to be kept on file with the relevant extranet group.  All non-publicly accessible information is the sole property of XXX.

 6.3 Business Case

All extranet connections or network resource access must be accompanied by a valid business justification, in writing, that is approved by both the third party and the corresponding KDCC contracting authority or rightful designee. Typically this function is handled as part of the Third Party Agreement.

6.4 Point Of Contact

The KDCC contracting authority must designate a person to be the Point of Contact (POC) for the third-party connection. The POC acts on behalf of the KDCC contracting authority and is responsible for those portions of this policy and the “Third Party Agreement” that pertain to it. In the event that the POC changes, the relevant third party person or organization, must be informed promptly.

6.5 Establishing Connectivity

All contracting authorities within that wish to establish connectivity or network resource access to a third party are to file an Extranet connectivity request with IT Manager accompanied by a “Third Party Agreement” signed by the third party person, organization, or rightful designee.  IT Manager will then engage the third party to address security issues inherent in the project. The sponsoring contract authority must provide full and complete information as to the nature of the proposed access to the IT Manager, as requested. All connectivity established must be based on the least-access principle, in accordance with the approved business requirements and the security review. All connectivity requests will have a specific beginning and ending date.  In no case will rely upon the third party to protect the network or resources.  IT Manager will grant access to all approved resources and reserves the right to refuse access on the basis of legitimate security concerns as decided by the CISO.

6.6 Modifying or Changing Connectivity and Access

All changes in access must be accompanied by a valid business justification, and are subject to security review.  The sponsoring contracting authority is responsible for notifying the third party person or organization and IT Manager when there is a material change in their originally provided information so that security and connectivity evolve accordingly.  Extensions will be granted on a case-by-case basis and must be requested in writing by the sponsoring contracting authority.

6.7 Terminating Access

When access is no longer required, the sponsoring contracting authority within XXX must notify the IT Manager, who will then terminate the access. This may mean a modification of existing permissions up to terminating the circuit, as appropriate. IT security teams must conduct an audit of their respective connections on an annual basis to ensure that all existing connections are still needed and that the access provided meets the needs of the connection. Connections that are found to be deprecated, and/or are no longer being used to conduct business or other approved business transactions will be terminated immediately. Should a security incident or a finding that a circuit has been deprecated and is no longer being used to conduct business or other approved business transactions necessitate a modification of existing permissions, or termination of connectivity, the IT Manager will notify the POC of the sponsoring contracting authority of the change prior to taking any action.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Information Security Operations Management Procedure

A. Operational Procedures and Responsibilities

1. Documented Operating Procedures

1.1 Operating procedures and responsibilities for information systems must be authorised, documented and maintained.
1.2 Information Owners and System Owners must ensure that Standard Operating Procedures (SOP) and standards are:

  1. documented;
  2. approved by the appropriate authority;
  3. consistent with University policies;
  4. reviewed and updated periodically;
  5. reviewed and updated when there are changes to equipment/systems or changes in business services and the supporting information systems operations; and
  6. reviewed and updated following a related security incident investigation.

1.3 The documentation must contain detailed instructions regarding:

  1. information processing and handling;
  2. system restart and recovery procedures;
  3. backup and recovery including on-site and off-site storage;
  4. exceptions handling, including a log of exceptions;
  5. output and media handling, including secure disposal or destruction;
  6. Management of audit and system log information;
  7. change management including scheduled maintenance and interdependencies;
  8. computer room management and safety;
  9. Information Incident Management Process;
  10. Disaster Recovery;
  11. Business Continuity Plan; and
  12. contact information for operations, technical, emergency and business personnel.

2. Change Management

2.1 Changes to business processes and information systems that affect information security must be controlled.
2.2 All changes to the Organization’s ICT services and systems environment, including provisioning and de-provisioning of assets, promotion of code, configuration changes and changes to Standard Operating Procedures must be authorised by the IT Change Advisory Board (CAB).
2.3 The change management process must follow the guidelines, approvals and templates provided as per the Transition Process.
2.4 Changes must be controlled by:

  1. identifying and recording significant changes;
  2. assessing the potential impact, including that on security, of the changes;
  3. obtaining approval of changes from those responsible for the information system;
  4. planning and testing changes including the documentation of rollback procedures;
  5. communicating change details to relevant personnel, Users and stakeholders; and
  6. evaluating that planned changes were implemented as intended.

2.5 Information Owners and System Owners must plan for changes by:

  1. assessing the potential impact of the proposed change on security by conducting a security review and a Threat and Risk Assessment;
  2. identifying the impact on agreements with business partners and external parties including information sharing agreements, licensing and provision of services;
  3. preparing change implementation plans that include testing and contingency plans in the event of problems;
  4. obtaining approvals from affected Information Owners; and
  5. training techniques of operational staff as necessary;

2.6 Information Owners and System Owners must implement changes by:

  1. notifying affected internal parties, business partners and external parties;
  2. following the documented implementation plans;
  3. training users if necessary;
  4. documenting the process throughout the testing and implementation phases; and
  5. confirming the changes have been performed and no unintended changes took place

3. Capacity Management

3.1 The use of information system resources must be monitored and optimised with projections made of future capacity requirements.
3.2 Information Owners and System Owners are responsible for implementing capacity management processes by:

  1. documenting capacity requirements and capacity planning processes;
  2. including capacity requirements in service agreements; and
  3. monitoring and optimising information systems to detect impending capacity limit.

3.3 Information Owners and System Owners must project future capacity requirements based on:

  1. new business and information systems requirements;
  2. statistical or historical capacity requirements; and
  3. current and expected trends in information processing capabilities (e.g. the introduction of more efficient hardware or software).

3.4 Information Owners and System Owners must use trend information from the capacity management process to identify and remediate potential bottlenecks that present a threat to system security or services

4. Separation of Development, Testing and Production Environments

4.1 Development, testing and production environments must be separated to reduce the risks of unauthorised access or changes to the production environment.
4.2 Information Owners and System Owners must:

  1. separate production environments from test and development environments by using different servers, networks and where possible different domains;
  2. ensure that production servers do not host test or development services or applications;
  3. prevent the use of test and development identities as credentials for production systems;
  4. store source code in a secure location away from the production environment and restrict access to specified personnel;
  5. prevent access to compilers, editors and other tools from production systems;
  6. use approved change management processes for promoting software from development/test to production;
  7. prohibit the use of production data in development, test or training systems; and
  8. prohibit the use of sensitive information in development, test or training systems in accordance with the System Acquisition, Development and Maintenance Procedure

B. Protection from Malware

1. Controls Against Malicious Code

1.1 Detection, prevention and recovery controls – supported by user awareness procedures – must be implemented to protect against malware.
1.2 Information Owners and System Owners must protect University information systems from malicious code by:

  1. installing, updating and using software designed to scan, detect, isolate and delete malicious code;
  2. preventing unauthorised Users from disabling installed security controls;
  3. prohibiting the use of unauthorised software;
  4. checking files, email attachments and file downloads for malicious code before use;
  5. maintaining business continuity plans to recover from malicious code incidents;
  6. maintain a critical incident management plan to identify and respond to malicious code incidents;
  7. maintaining a register of specific malicious code countermeasures (e.g. blocked websites, blocked file extensions, blocked network ports) including a description, rationale, approval authority and the date applied; and
  8. developing user awareness programs for malicious code countermeasures.

1.3 The IT Security staff are responsible for communicating technical advice and providing information and awareness activities regarding malicious code

C. Backup

1. Information Backup

1.1 Backup copies of information, software and system images must be made, secured, and be available for recovery.
1.2 Information Owners and System Owners must define and document backup and recovery processes that consider the confidentiality, integrity and availability requirements of information and information systems.
1.3 Backup and recovery processes must comply with:

  1. University business continuity plans (if applicable);
  2. policy, legislative, regulatory and other obligations; and
  3. records management requirements (refer Records Management Policy).

1.4 The documentation for backup and recovery must include:

  1. types of information to be backed up;
  2. schedules for the backup of information and information systems;
  3. backup media management;
  4. methods for performing, validating and labelling backups; and
  5. methods for validating the recovery of information and information systems.

1.5 Backup media and facilities must be appropriately secure based on a security review or Risk Assessment. Controls to be applied include:

  1. use approved encryption;
  2. physical security;
  3. access controls;
  4. methods of transit to and from off-site locations;
  5. appropriate environmental conditions while in storage; and
  6. off-site locations must be at a sufficient distance to escape damage from an event at the main site principles

D. Log Management

1. Event Logging

1.1 Event logs recording user activities, exceptions, faults and information security events must be produced, kept and regularly reviewed.
1.2 Information Owners must ensure that event logs are used to record user and system activities, exceptions and events (security and operational). The degree of detail to be logged must be based on the value and sensitivity of the information and the criticality of the system. The resources required to analyse the logs must also be considered. Where applicable, event logs must include:

  1. user ID;
  2. system activities;
  3. dates, times and details of key events (e.g. login, logoff);
  4. device identity and location;
  5. login method;
  6. records of successful and unsuccessful system access attempts;
  7. records of successful and unsuccessful data and other resource access attempts;
  8. changes to system configuration;
  9. use of elevated privileges;
  10. use of system utilities and applications;
  11. network addresses and protocols;
  12. alarms raised by the access control system;
  13. activation and de-activation of protection systems (e.g. anti-virus, intrusion detection); and
  14. records of transactions executed by users in applications.

1.3 Event logs may contain sensitive information and therefore must be safeguarded in accordance with the requirements of the section on the Protection of Log Information.
1.4 System administrators must not have the ability to modify, erase or de-activate logs of their own activities.
1.5 If event logging is disabled the decision must be documented. Include the name and position of the approver, date and rationale for de-activating the log.
1.6 Event logs may be configured to alert someone if certain events or signatures are detected. Information Owners and System Owners must establish and document alarm response procedures to ensure they are responded to immediately and consistently. Normally, response to an alarm will include:

  1. identification of the event;
  2. isolation of the event and affected assets;
  3. identification and isolation of the source;
  4. corrective action;
  5. forensic analysis;
  6. action to prevent recurrence; and
  7. securing event logs as evidence

2. Protection of Log Information

2.1 Information system logging facilities and log information must be protected against tampering and unauthorised access.
2.2 Information Owners must implement controls to protect logging facilities and log files from unauthorised modification, access or destruction. Controls must include:

  1. physical security safeguards;
  2. permission for administrators and operators to erase or de-activate logs;
  3. multifactor authentication for access to highly-restricted records;
  4. backup of audit logs to off-site facilities;
  5. automatic archiving of logs to remain within storage capacity; and
  6. scheduling the audit logs as part of the records management process.

2.3 Event logs must be retained in accordance with the records retention schedule for the information system.
2.4 System logs for University critical IT infrastructure (P1 list) must be retained for at least 30 days online and archived for 90 days.
2.5 Datacentre physical access logs must be made available for at least 90 days and CCTV records must be retained for at least 30 days.
2.6 Logs must be retained indefinitely if an investigation has commenced or it is known that evidence may be obtained from them

3. Administrator and Operator Logs

3.1 Activities of privileged users must be logged and the log subject to regular independent review.
3.2 The activities of system administrators, operators and other privileged users must be logged including:

  1. the time an event (e.g. success or failure) occurred;
  2. event details including files accessed, modified or deleted, errors and corrective action is taken;
  3. the account and the identity of the privileged user involved; and
  4. the systems processes involved.

3.3 Logs of the activities of privileged users must be checked by the Information Owner or delegate. Checks must be conducted regularly and randomly. The frequency must be determined by the value and sensitivity of the information and criticality of the system. Following verification of the logs, they must be archived in accordance with the applicable records retention schedule.

4. Clock Synchronisation

4.1 Computer clocks must be synchronised for accurate recording.
4.2 System administrators must synchronise information system clocks to the local router gateway or a University-approved host.
4.3 System administrators must confirm system clock synchronisation following power outages and as part of the incident analysis and event log review

E. Control of Operational Software

1. Installation of Software on Production Systems

1.1 The installation of software on production information systems must be controlled.
1.2 To minimise the risk of damage to production systems Information Owners must implement the following procedures when installing software:

  1. updates of production systems must be planned, approved, assessed for impacts, tested and logged;
  2. a Change and Release Coordinator must be appointed to coordinate the install and update of software, applications and program libraries;
  3. operations personnel and end users must be notified of the changes, potential impacts and, if required, given additional training;
  4. production systems must not contain development code or compilers;
  5. user acceptance testing must be extensively and successfully conducted on a separate system prior to production implementation;
  6. a rollback strategy must be in place and previous versions of application software retained;
  7. old software versions must be archived with configuration details and system documentation; and
  8. updates to program libraries must be logged

F. Vulnerability Management

1. Management of Technical Vulnerabilities

1.1 Regular assessments must be conducted to evaluate information system vulnerabilities and the management of associated risk.
1.2 To support technical vulnerability management, Information Owners and System Owners must maintain an inventory of information assets in accordance with the Information Security Asset Management Procedure. Specific information must be recorded including:

  1. the software vendor;
  2. version numbers;
  3. the current state of deployment; and
  4. the person(s) responsible for the system.

1.3 Vulnerabilities which impact the information systems must be addressed in a timely manner to mitigate or minimise the impact on the operations. The IT Security Team shall ensure that vulnerability assessments (VA) are conducted for the organization’s ICT services and systems on a regular basis.
1.4 Vulnerability remediation efforts, including patch implementations, shall be coordinated and processed according to the Patch Management Procedure and Risk Management Framework.
1.5 All internal and external organization ICT systems and resources are covered in this Procedure:
(a) Internal Vulnerability Assessments

  1. Servers used for internal hosting and supporting Infrastructure
  2. Servers which will be accessed through the reverse proxy
  3. Research specific servers and applications
  4. Research devices and systems
  5. Desktops and workstations

(b) External Vulnerability Assessments

  1. Perimeter network devices exposed to the internet
  2. All external facing servers and services
  3. Network appliances, streaming devices and essential IP assets that are internet facing.
  4. Public-facing research applications and devices
  5. Cloud-based services

2. Vulnerability Management Cycle

2.1 Asset Discovery

  1. Asset Discovery scan will be executed on a monthly basis or quarterly on the segments to determine the live assets connected to the network.
  2. The network team will share the IP segments of all assets within the University including Datacentres and other Virtual LANs with the IT Security Team.
  3. IT Security Team will perform an asset discovery scan on the segments.
  4. Any assets added or removed from the segment will be detected in the asset discovery scan.
  5. IT Security Team will share with the Network team the addition/removal of servers/devices for reconfirmation based on the discovery scan.
  6. The final list of IP/IP Segments will be scanned for Vulnerabilities

2.2 Scan – Remediate – Rescan

  1. IT Security team shall perform Vulnerability Analysis Scan on all University Critical Infrastructure Servers on a monthly basis and non-critical assets on at least a quarterly basis.
  2. IT Security Team will perform a risk assessment to map the risk, threat, likelihood and impact rating for the vulnerabilities noted.
  3. The University Risk Management Framework shall be followed to perform the risk assessment.
  4. IT Security Team shall inform the System Owners regarding the results of the scans and share the vulnerability reports with the Responsible Administrators for each system.
  5. All vulnerabilities identified in the VA Scan shall be remediated by according to the Remediation timeline.
  6. The System Owners shall inform IT Security Team regarding the completion of vulnerability remediation.
  7. Vulnerabilities that cannot be actioned within the defined timeframe will need an exception approved.

2.3 Ad-Hoc Scans

Ad-hoc scans include scans on any new infrastructure devices/servers/services prior to production deployment as per the following process.

  1. New service owners shall complete a Service Desk request ticket and submit to the IT Security Team for action.
  2. The IT Security Team shall perform Vulnerability Analysis Scan of specific systems (including servers) as per the environment and technology used for the system.
  3.  VA report shall be submitted to the Business owner and respective System Owner or team.
  4. IT Security Team lead will validate with respective System Owners on the closure of all the vulnerabilities and then perform a rescan.
  5. Vulnerabilities that cannot be actioned within the defined timeframe will need an exception approved, with risk acceptance and compensating controls implemented and documented.
  6. Assets/ services/devices can be released to production only after the final sign off by IT Security Team

3. Classification of Vulnerabilities

3.1 Vulnerabilities are classified based on their impact in a given environment, to data/information or to the University’s reputation Rating

RatingRed Hat,  Microsoft, Adobe
Rating
Typical CVSS
Score
Description
CriticalCritical10A vulnerability whose exploitation could allow code execution or complete system compromise without user interaction. These scenarios include self-propagating malware or unavoidable common use scenarios where code execution occurs without warnings or prompts. This could include browsing to a web page or opening an email or no action at all.
HighImportant7.0 – 9.9A vulnerability whose exploitation could result in the compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources. This includes common use scenarios where a system is compromised with warnings or prompts, regardless of their provenance, quality, or usability. Sequences of user actions that do not generate prompts or warnings are also covered.
MediumModerate4.0 – 6.9The impact of the vulnerability is mitigated to a significant degree by factors such as authentication requirements or applicability only to non-default configurations. The vulnerability is normally difficult to exploit.
LowLow< 4.0This classification applies to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

4. Remediation Timeline and Risk Acceptance

4.1 All vulnerabilities identified in a VA Scan shall be addressed within the timeline described below. If any particular vulnerability cannot be remediated within this timeframe, the risk of data loss/attack on the device should be formally documented and accepted by the respective groups in the below table. Remediation time and risk acceptance for the identified vulnerabilities shall be as follows:

Vulnerability LevelRemediation TimelinesRisk Acceptance
External Facing DevicesInternal Devices
Critical1 Week1 WeekCIO or Risk Management Office
High2 Weeks2 WeeksCIO
Medium3 WeeksNext Maintenance WindowInformation Owner
LowNext Maintenance WindowNext Maintenance WindowInformation Owner

5. Third-Party Scans

5.1 A third party must be engaged annually to perform vulnerability assessment & penetration testing covering all internet-facing organization ICT services and systems and critical internal non-internet facing ICT services and systems.

6. Vulnerability Management Roles and Responsibilities

6.1 IT Security Team

  1. Perform asset discovery and performing Vulnerability Management Process
  2. Approve the Vulnerability Assessment Schedule
  3. Oversee vulnerability remediation.
  4. Targeting vulnerability program maturity through metrics development
  5. Monitor security sources for vulnerability announcements and emerging threats that correspond to the system inventory.

6.2 System Owners

  1. Responsible for implementing remediating actions defined as a result of detected vulnerabilities.
  2. testing and evaluating options to mitigate or minimize the impact of vulnerabilities;
  3. applying corrective measures to address the vulnerabilities, and
  4. reporting to the IT Security Team on progress in responding to vulnerabilities

6.3 Depending on how urgently a technical vulnerability needs to be addressed, the action taken should be carried out according to the change management controls or by following the Information Security Incident Management Guidelines.
6.4 Responsibilities for vulnerability response must be included in service agreements with suppliers.

7. Restrictions on Software Installation

7.1 Rules governing the installation of software by users must be established and implemented.
7.2 Users are not allowed to install software on University devices unless specifically authorized by a System Owner or a system administrator. System Owners are responsible for the installation of software, updates, and patches.

H. Information Security Audit Considerations

1. Information Systems Audit Controls

1.1 Audit requirements and activities involving checks on production systems must be planned and approved to minimize disruption to business processes.
1.2 Prior to commencing compliance checking activities such as audits or security reviews of production systems the CIO, and the Information Owner must define, document and approve the activities. Among the items upon which they must agree are:

  1. the audit requirements and scope of the checks;
  2. audit personnel must be independent of the activities being audited;
  3. the checks must be limited to read-only access to software and data, except for isolated copies of system files, which must be erased or given appropriate protection if required when the audit is complete;
  4. the resources performing the checks must be explicitly identified;
  5. existing security metrics will be used where possible;
  6. all access must be monitored and logged and all procedures, requirements and responsibilities must be documented;
  7. audit tests that could affect system availability must be run outside business hours; and
  8. appropriate personnel must be notified in advance in order to be able to respond to any incidents resulting from the audit.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Capacity Management procedure for Information Security Management System

Capacity Management is the continuous and iterative process that monitors, analyses, and evaluates the performance and capacity of the IT infrastructure and, with the data obtained, it optimizes the service or submits an RFC to Change Management. All the information obtained in these activities, and that generated by Capacity Management using that information, is stored and recorded in the Capacity Database (CDB) available with the IT Manager.

1

1.Monitoring

The main objective is to ensure that the performance of the IT infrastructure matches the requirements of the SLAs. As well as technical aspects, monitoring needs to include details of licenses and other administrative information.

2. Analysis and Evaluation

The data collected needs to be analyzed to assess whether corrective action needs to be taken, such as requesting an increase in capacity or better Demand Management.

3. Optimization and changes

If it is decided that capacity needs to be increased, an RFC will be raised and sent to Change Management to set in train the whole process involved in implementing the change. Capacity Management will lend its support throughout the process and it will be jointly responsible, together with Change Management and Release Management for ensuring that the change requested meets the envisaged objectives. In the case where a simple rationalization of demand will be enough to resolve the deficiencies or non-compliances with SLAs, Capacity Management itself will be responsible for managing this sub-process.

4. Capacity Database

The CDB must cover all the business, financial, technical, and service information received and generated by Capacity Management in relation to the capacity of the infrastructure and its elements. Ideally, the CDB must be interrelated with the CMDB so that the CMDB is able to give a complete image of the systems and applications and includes all the information about their capacity. However, this does not mean that the two databases cannot be “physically independent”.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Disciplinary procedure for Information Security Management System

1.0 Purpose and scope

This procedure is designed to help and encourage all employees to achieve and maintain standards of conduct, attendance, and job performance. This procedure applies to all employees. The aim is to ensure consistent disciplinary procedures for all in the organization.

2.0 Principles

Counseling will be offered, where appropriate, to resolve problems. No disciplinary action will be taken against an employee until the case has been fully investigated. At every stage in the procedure, the employee will be advised of the nature of the complaint against him or her and will be given the opportunity to state his or her case before any decision is made. The procedure may be implemented at any stage if the employee’s alleged misconduct warrants such action. The minimum three-step statutory procedures will be followed if an employee faces dismissal or certain kinds of action short of dismissal.

3.0 The Procedure

Stage 1 – improvement note: unsatisfactory performance

If performance does not meet acceptable standards the employee will normally be given an improvement note. This will set out the performance problem, the improvement that is required, the timescale, and any help that may be given. The individual will be advised that it constitutes the first stage of the formal procedure. A record of the improvement note will be kept for 6 months, but will then be considered spent – subject to achievement and sustainment of satisfactory performance.

Stage 2 – First warning: misconduct

If the conduct does not meet acceptable standards the employee will normally be given a written warning. This will set out the nature of the misconduct and the change in behavior required. The warning should also inform the employee that a final written warning may be considered if there is no sustained satisfactory improvement or change. A record of the warning should be kept, but it should be disregarded for disciplinary purposes after a specified period (eg, six months).

Stage 3: Final written warning

If the offense is sufficiently serious, or there is a failure to improve during the currency of a prior warning for the same type of offense, a final written warning may be given to the employee. This will give details of the complaint, the improvement required, and the timescale. It will also warn that failure to improve may lead to action under Stage 3 (dismissal or some other action short of dismissal), and will refer to the right of appeal. A copy of this written warning will be kept by the supervisor but will be disregarded for disciplinary purposes after 6 months subject to achievement and sustainment of satisfactory conduct or performance.

Stage 4 – dismissal or other sanction

If there is still a failure to improve the final step in the procedure may be dismissal or some other action short of dismissal such as demotion or disciplinary suspension or transfer (as allowed in the contract of employment). Dismissal decisions can only be taken by the appropriate senior manager, and the employee will be provided, as soon as reasonably practicable, with written reasons for dismissal, the date on which the employment will terminate, and the right of appeal. The decision to dismiss will be confirmed in writing. If some sanction short of dismissal is imposed, the employee will receive details of the complaint, will be warned that dismissal could result if there is no satisfactory improvement, and will be advised of the right of appeal. A copy of the written warning will be kept by the supervisor but will be disregarded for disciplinary purposes after 6 months subject to achievement and sustainment of satisfactory conduct or performance.

Statutory discipline and dismissal procedure

If an employee faces dismissal – or certain action short of dismissals such as loss of pay or demotion – the minimum statutory procedure will be followed. This involves:  

  • Step one: a written note to the employee setting out the allegation and the basis for it

  • Step two: a meeting to consider and discuss the allegation

  • Step three: a right of appeal including an appeal meeting.

The employee will be reminded of their right to be accompanied.

Gross misconduct

The following list provides examples of offenses that are normally regarded as gross misconduct:

  • theft, fraud, deliberate falsification of records
  • fighting, assault on another person
  • deliberate damage to organizational property
  • serious incapability through alcohol or being under the influence of illegal drugs
  • serious negligence which causes unacceptable loss, damage, or injury
  • a serious act of insubordination
  • unauthorized entry to computer records.

If you are accused of an act of gross misconduct, you may be suspended from work on full pay, normally for no more than five working days, while the alleged offense is investigated. If on completion of the investigation and the full disciplinary procedure, the organization is satisfied that gross misconduct has occurred, the result will normally be summary dismissal without notice or payment in lieu of notice.

Appeals

An employee who wishes to appeal against a disciplinary decision must do so within five working days. The senior manager will hear all appeals and his/her decision is final. At the appeal, any disciplinary penalty imposed will be reviewed.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Software installation policy

1. Policy Statement

This policy is designed to let XXX’s employees achieve their business objectives. Any aberrations from this strategy will require the IT department to redeploy software and/or hardware solutions. Full cooperation with this policy is appreciated so that all goals can be met in accordance with the business objectives.

2. Purpose

The purpose of this policy is to address all issues relevant to software installation and deployment on XXX’s computer systems. IT objective is to enable its employees to perform their tasks with technology that is in good operating condition while appropriately addressing the business needs.

3. Scope

3.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of the software installation Policy, and related procedures & guidelines. The Compliance Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

3.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any). This policy has full support from the executive steering committee and human resources. This policy is a living document and may be modified at any time by the IT manager, human resources, or the executive steering committee.

6 Policy

6.1 Installation and support of  software

The IT department is exclusively responsible for installing and supporting all software on company computers. This responsibility set includes:

  • Office desktop computers.
  • Company laptop computers.

The IT department relies on installation and support to provide software and hardware in good operating conditions to employees so that they can best accomplish their tasks.

6.2 Current Software

The current software can exist in any one of the following scenarios:

  • An IT-created “image” or OEM installation on the hardware
  • An IT department installation procedure that provides for the following:
    • Installation options
    • Upgrade considerations (if applicable)
    • Data conversion (if applicable)
  • A shortcut to a network application (not truly an installation)
  • An automated installation through an IT-developed solution that may be used in a rapid-deployment scenario or silent-install situation
  • A terminal application, Server application, or other thin-client types of application accessible via the KDCC, intranet page

The software cannot be present on  XXX’s computers in the following scenarios:

  • An installation not by a procedure
  • A piece of software purchased for one’s home computer
  • A downloaded title from the Internet
  • A pirated copy of any title
  • A different title from the current software list of this policy
  • Any means not covered by the ways that software can exist on KDCC, computers

6.3 Software licensing

Most of the software titles on the current software list are not freeware; therefore, the cost of software is a consideration for most titles and their deployment. It is the goal of the IT department to keep licensing accurate and up to date. To address this, the IT department is responsible for purchasing software licenses for the following software categories:

  • Desktop operating system software
  • Productivity tools package
  • Internet software
  • Accessories

The other software categories (workgroup-specific titles) are the purchasing responsibility of the workgroup in which they serve. However, the application(s) are still installed and supported by the IT department. To control costs, licensing costs are a factor in the decision-making processes that go into client software planning and request approval.

6.4 Unauthorized software

Do not download, install or use unauthorized software programs. Unauthorized software could introduce serious security vulnerabilities into the networks as well as affecting the working of your laptop. Software packages that permit the computer to be ‘remote-controlled’ (e.g. PC anywhere) and ‘hacking tools’ (e.g. network sniffers and password crackers) are explicitly forbidden on equipment unless they have been explicitly pre-authorized by management for legitimate business purposes.

6.5 Unlicensed software

Be careful about software licenses. Most software, unless it is specifically identified as “freeware” or “public domain software”, may only be installed and/or used if the appropriate license fee has been paid. Shareware or trial packages must be deleted or licensed by the end of the permitted free trial period. Some software is limited to free use by private individuals whereas commercial use requires a license payment. Individuals and companies are being prosecuted for infringing software copyright: do not risk bringing yourself and XXX into disrepute by breaking the law.

6.6 Software requests

If a user is to request software for their computer, the proper method will be to send a request to the IT manager. A response is guaranteed within one business day via e-mail. If the Urgent option is selected or an in-person appearance occurs, a solution may be delivered at the first possible time. All in-person or “walk-in” requests are logged by manual entry into the support request system to track licensing needs and costs.

6.7 Laws, regulations and policies

You must comply with relevant laws, regulations, and policies applying to the use of computers and information. Software licensing has already been mentioned and privacy laws are another example. Various corporate security policies apply to laptops, the data they contain, and network access (including use of the Internet).

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Laptop Security Policy

1. Policy Statement

All computer systems face information security risks. Laptop computers are an essential business tool but their very portability makes them particularly vulnerable to physical damage or theft. Furthermore, the fact that they are often used outside XXX’s premises increases the threats from people who do not work for the XXX and may not have its interests at heart. Portable computers are especially vulnerable to physical damage or loss, and theft, either for resale (opportunistic thieves) or for the information they contain (industrial spies). Do not forget that the impacts of such breaches include not just the replacement value of the hardware but also the value of any XXX data on them, or accessible through them. Information is a vital KDCC asset. We depend very heavily on our computer systems to provide complete and accurate business information when and where we need it. The impacts of unauthorized access to, or modification of, important and/or sensitive XXX data can far outweigh the cost of the equipment itself. This policy refers to certain other/general information security policies, but the specific information given here is directly relevant to laptops and, in case of conflict, takes precedence over other policies.

2. Purpose

This policy describes the controls necessary to minimize information security risks affecting XXX laptops.

3. Scope

3.1 Employees

This policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of Laptop security Policy, and related procedures & guidelines. The Compliance Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

3.3 Records

Records being generated as part of this Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

This Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

This Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

This Policy shall be implemented by the CISO  and designated personnel (if any).

6 Policy

6.1 Physical security controls for laptops

  • The physical security of ‘your’ laptop is your personal responsibility so please take all reasonable precautions. Be sensible and stay alert to the risks.
  • Keep your laptop in your possession and within sight whenever possible, just as if it were your wallet, handbag or mobile phone. Be extra careful in public places such as airports, railway stations or restaurants. It takes thieves just a fraction of a second to steal an unattended laptop.
  • If you have to leave the PC temporarily unattended in the office, meeting room or hotel room, even for a short while, use a laptop security cable or similar device to attach it firmly to a desk or similar heavy furniture. These locks are not very secure but deter casual thieves.
  • Lock the laptop away out of sight when you are not using it, preferably in a strong cupboard, filing cabinet or safe. This applies at home, in the office or in a hotel. Never leave a laptop visibly unattended in a vehicle. If absolutely necessary, lock it out of sight in the trunk or glove box but it is generally much safer to take it with you.
  • Carry and store the laptop in a padded laptop computer bag or strong briefcase to reduce the chance of accidental damage. Don’t drop it or knock it about! Bubble-wrap packaging may be useful. An ordinary-looking briefcase is also less likely to attract thieves than an obvious laptop bag.
  • Keep a note of the make, model, serial number and the asset label of your laptop but do not keep this information with the laptop. If it is lost or stolen, notify the Police immediately and inform the IT Help/Service Desk as soon as practicable (within hours not days, please).

6.2 Virus protection of laptops

  • Viruses are a major threat to and laptops are particularly vulnerable if their anti-virus software is not kept up-to-date. The anti-virus software MUST be updated at least monthly. The easiest way of doing this is simply to log on to the network for the automatic update process to run. If you cannot log on for some reason, contact the IT Help/Service Desk for advice on obtaining and installing anti-virus updates.
  • Email attachments are now the number one source of computer viruses. Avoid opening any email attachment unless you were expecting to receive it from that person.
  • Always virus-scan any files downloaded to your computer from any source (CD/DVD, USB hard disks and memory sticks, network files, email attachments or files from the Internet). Virus scans normally happen automatically but the IT Help/Service Desk can tell you how to initiate manual scans if you wish to be certain.
  • Report any security incidents (such as virus infections) promptly to the IT Help/Service Desk in order to minimize the damage.
  • Respond immediately to any virus warning message on your computer, or if you suspect a virus (e.g. by unusual file activity) by contacting the IT Help/Service Desk. Do not forward any files or upload data onto the network if you suspect your PC might be infected.
  • Be especially careful to virus-scan your system before you send any files outside the XXX. This includes EMAIL attachments and CD-ROMs that you create.

6.3 Controls against unauthorized access to laptop data

  • You must use approved encryption software on all corporate laptops, choose a long, strong encryption password/phrase and keep it secure. Contact the IT Help/Service Desk for further information on laptop encryption. If your laptop is lost or stolen, encryption provides extremely strong protection against unauthorized access to the data.
  • You are personally accountable for all network and systems access under your user ID, so keep your password absolutely secret. Never share it with anyone, not even members of your family, friends or IT staff.
  • Corporate laptops are provided for official use by authorized employees. Do not loan your laptop or allow it to be used by others such as family and friends.
  • Avoid leaving your laptop unattended and logged-on. Always shut down, log off or activate a password-protected screensaver before walking away from the machine.
    Other controls for laptops

6.4 Unauthorized software

Do not download, install or use unauthorized software programs. Unauthorized software could introduce serious security vulnerabilities into the networks as well as affecting the working of your laptop. Software packages that permit the computer to be ‘remote controlled’ (e.g. PC anywhere) and ‘hacking tools’ (e.g. network sniffers and password crackers) are explicitly forbidden on equipment unless they have been explicitly pre-authorized by management for legitimate business purposes.

6.5 Unlicensed software

Be careful about software licenses. Most software, unless it is specifically identified as “freeware” or “public domain software”, may only be installed and/or used if the appropriate license fee has been paid. Shareware or trial packages must be deleted or licensed by the end of the permitted free trial period. Some software is limited to free use by private individuals whereas commercial use requires a license payment. Individuals and companies are being prosecuted for infringing software copyright: do not risk bringing yourself and XXX into disrepute by breaking the law.

6.6 Backups

Unlike desktop PCs which are backed up automatically by IT, you must take your own backups of data on your laptop. The simplest way to do this is to log in and upload data from the laptop to the network on a regular basis – ideally daily but weekly at least. If you are unable to access the network, it is your responsibility to take regular off-line backups to CD/DVD, USB memory sticks, etc. Make sure that off-line backups are encrypted and physically secured. Remember, if the laptop is stolen, lost, or damaged, or if it simply malfunctions, it may be impossible to retrieve any of the data from the laptop. Off-line backups will save you a lot of heartaches and extra work.

6.7 Laws, regulations and policies

You must comply with relevant laws, regulations, and policies applying to the use of computers and information. Software licensing has already been mentioned and privacy laws are another example. Various corporate security policies apply to laptops, the data they contain, and network access (including use of the Internet).

6.8 Inappropriate materials

XXX will not tolerate inappropriate materials such as pornographic, racist, defamatory, or harassing files, pictures, videos, or email messages that might cause offense or embarrassment. Never store, use, copy or circulate such material on the laptop and steer clear of dubious websites. IT staff routinely monitor the network and systems for such materials and track the use of the Internet: they will report serious/repeated offenders and any illegal materials directly to management, and disciplinary processes will be initiated. If you receive inappropriate material by email or other means, delete it immediately. If you accidentally browse to an offensive website, click ‘back’ or close the window straight away. If you routinely receive a lot of spam, call the IT Help/Service Desk to check your spam settings.

6.9 Health and safety aspects of using laptops

Laptops normally have smaller keyboards, displays, and pointing devices that are less comfortable to use than desktop systems, increasing the chance of repetitive strain injury. Balancing the laptop on your knees hardly helps the situation! Limit the amount of time you spend using your laptop. Wherever possible, place the laptop on a conventional desk or table and sit comfortably in an appropriate chair to use it. If you tend to use the laptop in an office most of the time, you are advised to use a ‘docking station’ with a full-sized keyboard, a normal mouse and a display permanently mounted at the correct height. Stop using the portable and consult Health and Safety for assistance if you experience symptoms such as wrist pain, eye strain, or headaches that you think may be caused by the way you are using the portable.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

Example of Compliance Policy in Information Security Management System

1. Policy Statement

XXX is committed to managing its legal and contractual compliance obligations in a proactive, ongoing, and responsible manner. It is committed to not only identifying the legislation which it is obliged to comply with but also measuring the levels of compliance in the organization. A Legal and Contractual Compliance Programme is a system for identifying and monitoring compliance with legislation and contractual agreements. It also attempts to raise employee awareness of legal and contractual obligations and aims to embed a compliance culture within the organization.

2. Purpose

This policy provides guidance to prevent breaches of any criminal and civil law, statutory, regulatory, or contractual obligations.

3. Scope

3.1 Employees

his policy applies to all  Employees, Contractors, and Third Party Employees, who use, process, and manage information and business processes of XXX.

3.2 Documentation

The documentation shall consist of Compliance Policy, and related procedures & guidelines. The Compliance Policy document and all other referenced documents shall be controlled. Version control shall be to preserve the latest release and the previous version of any document. However, the previous version of the documents shall be retained only for a period of two years for legal and knowledge preservation purposes.

3.3 Records

Records being generated as part of the Compliance Policy shall be retained for a period of two years. Records shall be in hard copy or electronic media. The records shall be owned by the respective system administrators and shall be audited once a year.

3.4 Distribution and Maintenance

The Compliance Policy document shall be made available to all the employees covered in the scope. All the changes and new releases of this document shall be made available to the persons concerned. The maintenance responsibility of the document shall be with the CISO and system administrators.

4. Privacy

The Compliance Policy document shall be considered as “confidential” and shall be made available to the concerned persons with proper access control. Subsequent changes and versions of this document shall be controlled.

5. Responsibility

The Compliance Policy shall be implemented by the CISO / designated personnel and Compliance Officer (if any).

6 Policy

The organization shall explicitly define and document its approach to meet all legal, regulatory, and contractual requirements. Issues of data protection, restrictions on the use of specific technology, compliance with security policies and standards must be defined and documented. Legal advice shall be sought and all above-mentioned documents shall be kept up to date.

7 Enforcement

Any employee found to have violated this policy may be subjected to disciplinary action in line with the HR Policy.

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.