SecureMail Principles

You are viewing an ARCHIVED page.

SecureMail is being designed in accordance with a set of policy and implementation principles:

Policy principles:

• Security - suitable protection must be provided for information provided by both people and the Crown.
• Acceptability - ensuring that the proposed approach is generally acceptable to potential users, taking into account the different needs of people and emerging industry standards, and avoids creating barriers.
• Protection of Privacy - ensuring that the proposed approach protects privacy appropriately.
• All-of-government approach - balancing public and agencies concerns about independence with the benefits of standardisation while delivering a cost effective solution.
• Fit for purpose - avoiding over-engineering, recognising that the levels of security required for government to people (G2P) transactions will vary based upon the nature of the information.

Implementation principles:

• User focus - ensuring the recommended solutions are as convenient, easy to use and non intrusive as possible.
• Enduring solution - providing a solution that is enduring yet sufficiently flexible to accommodate change and a wide range of current and future transactions.
• Affordability and reliability - ensuring the recommended solutions are affordable and reliable for the public and government agencies.
• Technology neutrality - ensuring a range of technology options are considered, and as far as possible avoiding vendor capture.
• Risk-based approach - providing an approach based on agreed security levels that protect identity and personal information.
• Legal compliance - the solution must comply with relevant law, including privacy and human rights law.
• Legal certainty - relationships between the parties should be governed in a way that provides legal certainty.
• Non-repudiation - the issue of non-repudiation must be considered for those transactions that require it, so that the risk of transacting parties later denying having participated in a transaction is minimised.
• Functional equivalence - requirements should be similar to those that apply to existing transactions except where the online nature of the transaction significantly changes the level of risk.