Purpose and Scope
This application security policy defines the security framework and requirements for
applications, notably web applications, within Helpwise’s production environment.
This document also provides implementing controls and instructions for web application security,
to include periodic vulnerability scans and other types of evaluations and assessments.
This policy applies to all applications within Helpwise’ production environment, as well as
administrators and users of these applications. This typically includes employees and
In order to minimize the risk of information loss or exposure (from both inside and outside
Helpwise), Helpwise is reliant on the principle of least privilege. Account creation and
permission levels are restricted to only the resources absolutely needed to perform each
person’s job duties. When a user’s role within Helpwise changes, those accounts and permission
levels are changed/revoked to fit the new role and disabled when the user leaves Helpwise
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.
Helpwise must ensure that all applications it develops and/or acquires are securely
configured and managed.
The following security best practices must be considered and, if feasible, applied as a
matter of the application’s security design:
Data handled and managed by the application must be classified in accordance with
Data Classification Policy.
If the application processes confidential information, a confidential record banner
be prominently displayed which highlights the type of confidential data being
(e.g., personally-identifiable information (PII), protected health information
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
Ensure that applications validate input properly and restrictively, allowing only
types of input that are known to be correct. Examples include, but are not limited
cross-site scripting, buffer overflow errors, and injection flaws.
Ensure that applications execute proper error handling so that errors will not
detailed system information to an unprivileged user, deny service, impair security
mechanisms, or crash the system.
Where possible, authorize access to applications by affiliation, membership or
employment, rather than by individual. Provide an automated review of authorizations
a regular basis, where possible.
Ensure that applications encrypt data at rest and in transit.
Implement application logging to the extent practical. Retain logs of all users and
access events for at least 14 days.
Qualified peers conduct security reviews of code for all new or significantly
applications; particularly, those that affect the collection, use, and/or display of
confidential data. Document all actions taken.
Implement a change management process for changes to existing software applications.
Standard configuration of the application must be documented.
Default passwords used within the application, such as for administrative control
or integration with databases must be changed immediately upon installation.
Applications must require complex passwords in accordance with current security best
practices (at least 8 characters in length, combination of alphanumeric
characters and symbols).
During development and testing, applications must not have access to live data.
Where applications are acquired from a third party, such as a vendor:
Only applications that are supported by an approved vendor shall be procured and
Full support contracts must be arranged with the application vendor for full
No custom modifications may be applied to the application without confirmation that
the vendor can continue to provide support.
Updates, patches and configuration changes issued by the vendor shall be implemented
as soon as possible.
A full review of applications and licenses shall be completed at least annually, as
part of regular software reviews.
Web applications must be assessed according to the following criteria:
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.
Third-party or acquired applications must have a full assessment prior to
Software releases must have an appropriate assessment, as determined by Helpwise’s
information security manager, with specific evaluation criteria based on the
security risks inherent in the changes made to the application’s functionality
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 CTO
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
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.
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.
Low - issues categorized as low risk must be reviewed to determine specific items to
be mitigated. Actions to implement mitigations must be scheduled.
Testing is required to validate fixes and/or mitigation strategies for any security
vulnerabilities classified as Medium risk or greater.
The following security assessment types may be leveraged to perform an application security
Full - comprised of tests for all known web application vulnerabilities using both
automated and manual tools based on the OWASP Testing Guide. A full assessment must
leverage manual penetration testing techniques to validate discovered
vulnerabilities to determine the overall risk of any and all discovered issues.
Quick - consists of an automated scan of an application for, at a minimum, the OWASP
Top Ten web application security risks.
Targeted - verifies vulnerability remediation changes or new application
To counter the risk of unauthorized access, Helpwise maintains a Data Center
Security requirements for the software development life cycle, including system
development, acquisition and maintenance are defined in the Software Development
Security requirements for handling information security incidents are defined in the
Security Incident Response Policy.
Disaster recovery and business continuity management policy is defined in the
Disaster Recovery Policy.
Requirements for information system availability and redundancy are defined in the
System Availability Policy.
Last updated: 2nd November 2021