diff --git a/docs/project/index.rst b/docs/project/index.rst
index 91ad6bc..d4717d1 100644
--- a/docs/project/index.rst
+++ b/docs/project/index.rst
@@ -12,7 +12,7 @@
     license
     maintainers
     versioning_policy
-
+    quality-assurance/index
 
 --------------
 
diff --git a/docs/project/quality-assurance/index.rst b/docs/project/quality-assurance/index.rst
new file mode 100644
index 0000000..775fce9
--- /dev/null
+++ b/docs/project/quality-assurance/index.rst
@@ -0,0 +1,30 @@
+Quality Assurance
+=================
+
+This section covers quality definition of the project, efforts the project is making to ensure the quality level of the
+products meet expectations.
+
+The primary products of this project are the :ref:`Deployments` building :ref:`Secure Partition Images` and `Libraries`.
+There are secondary products like:
+
+  - build scripts
+  - test automation scripts
+  - documentation
+  - various processes
+  - etc...
+
+Quality Assurance of secondary products happens at a "best effort" basis. The project will try to keep these healthy,
+but quality definition of these may aim lower or may even be lacking.
+
+.. toctree::
+   :maxdepth: 1
+
+   ./verification-strategy
+   ./verification-methodology
+   ./verification-plan
+
+--------------
+
+*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.*
+
+SPDX-License-Identifier: BSD-3-Clause
\ No newline at end of file
diff --git a/docs/project/quality-assurance/verification-methodology.rst b/docs/project/quality-assurance/verification-methodology.rst
new file mode 100644
index 0000000..f68401d
--- /dev/null
+++ b/docs/project/quality-assurance/verification-methodology.rst
@@ -0,0 +1,71 @@
+Verification methodology
+========================
+
+This page discusses discusses verification tools and techniques used by the project.
+
+
+Static Checks
+-------------
+
+This verification step checks quality by examining the source code. The project currently uses two tools which are
+discussed in the chapters below.
+
+Checkpatch
+''''''''''
+
+`Checkpatch`_ is a tool developed and maintained by the Linux Kernel community. It can look for errors related to:
+
+  - C and C++ coding style
+  - spelling mistakes
+  - git commit message formatting
+
+Please find the configuration of this tool in the :download:`TS repository.<../../../.checkpatch>`
+
+Cppcheck tool
+'''''''''''''
+
+`CppCheck`_ is a C/C++ static analysis tool. It can detect code depending on implementation defined behavior, and
+dangerous coding constructs and thus it verifies coding guidelines.
+
+Please find the configuration of this tool in the :download:`TS repository.<../../../.cppcheck>`
+
+Build verification
+------------------
+
+The :ref:`Build test runner` captures reference build configurations for all TS build products and can be used to verify
+these.
+
+Runtime verification
+--------------------
+
+During the runtime versification step various test and demo executables are executed on the host PC and/or on target
+platforms.
+
+Tests are targeting three different environment types:
+
+  - ``arm-linux``: test executables to be run from Linux user-space on the target.
+  - ``pc-linux``: executables to run on the host PC. These tests have a lower verification level, as the binary is likely
+    not running on an arm target. Portability issues in the source may hide error or trigger false alarms. In turn
+    this type of test is cheap,
+  - ``sp`` and ``opteesp``: test executables targeting these environments run in the SWd and server as:
+
+    - test payloads to help exercise trusted services
+    - test payload to help platform porting
+
+Each of these test applications manifest as a "deployment" in trusted services. For more details please see the
+:ref:`Deployments` section.
+
+Compliance testing
+''''''''''''''''''
+
+The project hosts deployment helping compliance testing. For more information please refer to
+:ref:`Platform Certification`.
+
+------------------
+
+.. _`Checkpatch`: https://docs.kernel.org/dev-tools/checkpatch.html
+.. _`CppCheck`: https://cppcheck.sourceforge.io/
+
+*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.*
+
+SPDX-License-Identifier: BSD-3-Clause
diff --git a/docs/project/quality-assurance/verification-plan.rst b/docs/project/quality-assurance/verification-plan.rst
new file mode 100644
index 0000000..3e67f43
--- /dev/null
+++ b/docs/project/quality-assurance/verification-plan.rst
@@ -0,0 +1,37 @@
+Verification Plan
+=================
+
+This document describes when and by whom verification steps are to be executed. Since this is an open-source project
+maintained by an open community, each contributor is expected to participate.
+
+Verification during development
+-------------------------------
+
+When changing existing code, or adding new code, the developer is expected to:
+
+  - run static checks to guard "clean code".
+  - execute runtime tests on the host machine to ensure features not changed are behaving as before. Verification
+    efforts targeting regression may be limited based on the expected effects of the change.
+  - extend unit and component tests to cover changes
+
+Verification during code review
+-------------------------------
+
+The code review covers all aspects of a change, including design and implementation. This includes running static checks
+and runtime tests. The reviewers are expected to check if tests are extended as needed.
+
+Verification efforts of a review may be limited to lower costs, based on the expected effects of the change.
+
+Guarding "main"
+---------------
+
+All commits of the integration branch shall be verified using the full verification set-up. This verification shall aim
+for achieving the highest quality level and shall not make compromises. A change becomes ready to get merged to "main"
+after passing the tests.
+
+
+--------------
+
+*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.*
+
+SPDX-License-Identifier: BSD-3-Clause
\ No newline at end of file
diff --git a/docs/project/quality-assurance/verification-strategy.rst b/docs/project/quality-assurance/verification-strategy.rst
new file mode 100644
index 0000000..db4a03d
--- /dev/null
+++ b/docs/project/quality-assurance/verification-strategy.rst
@@ -0,0 +1,98 @@
+Verification Strategy
+=====================
+
+This page describes verification from a high level concept perspective.
+
+In this context ``source code`` has a wider scope and may mean any text content produced by humans and processed by
+other humans or tools. Examples: C/C++ source code, reST documents, build scripts, etc...
+
+Clean Code
+----------
+
+Clean code aims to counterfeit issues discussed in the following sub-chapters.
+
+Code Readability
+''''''''''''''''
+
+Expressing ideas in a machine readable formats is complicated, and each developer may have a different taste or
+different preferences on how source code should be formatted. Some people may find a specific kind of formatting easier
+to understand than others. If the source code does not follow a consistent look and feel, human processing of the text
+may become error prone. This undermines effectiveness of co-operation and code-review, and may lead to incorrect code.
+The project defines coding style rules to counterfeit these problems. For detail please refer to :ref:`Coding Style &
+Guidelines`
+
+Undefined and Implementation Defined Behavior
+'''''''''''''''''''''''''''''''''''''''''''''
+
+The "standard" defining how to process a specific source code type, may leave some processing behavior to the tool
+to be defined, or allow the tool to behave in an undefined way. Coding constructs relying on such behavior are to be
+avoided, or used in a well defined way. This adds robustness and helps avoiding errors due to using different version
+of the same tool, or different implementations.
+
+The project defines coding guidelines to counterfeit these problems. For detail please refer to
+:ref:`Coding Style & Guidelines`
+
+Security
+''''''''
+
+Security is a complex topic affecting all steps of the development process. Incorrect code may lead to security issues
+and thus "Clean Code" has a vital role in implementing secure software.
+
+Runtime Testing
+---------------
+
+Runtime testing focuses of verifying the behavior of one or multiple build products built from source code. This can be
+done at multiple levels and in multiple execution environment.
+
+
+Unit Test
+'''''''''
+
+Unit tests aim to verify if the internal operation of a module matches the developers expectation. It helps covering all
+code execution paths, and to give confidence on correct operation when code needs to be refactored. Unit tests serve as
+a kind of documentation capturing the expected usage of the code.
+
+Unit-testing allays happen on the "host PC"
+
+Component Test
+''''''''''''''
+
+Component tests aim to verify the API (and ABI) of a component is matching expectations. Components are tested in
+isolation, where the exported APIs are exercised by these code, and APIs the component depends on are implemented by
+test doubles.
+
+System Test
+'''''''''''
+
+System test verifies correct operation of a set of modules configured to fulfill the requirements of a use-case. For TS
+this usually means testing and end-to-end setup on a specific target platform.
+
+Balancing Costs vs Quality
+''''''''''''''''''''''''''
+
+Executing build products on target platforms may have high costs in terms of time, complexity and availability and in
+turn it gives the hights confidence in verification results, or the best quality. In the development phase it may be
+desired to some level of this confidence for lower costs. For this purpose the project defines two main test
+set-up types based on the balance choice between cost and quality.
+
+Testing on a Target Platform
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In this environment tests are executed on a target platform. Emulators (e.g. QEMU, FVP) from this aspect are treated
+like targets implemented in silicon.
+
+Testing on the Host Machine
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In this environment test executables are compiled to execute as a "standard" user-space application running on the
+machine "hosting" the development activity. In most cases these machines are based on a different architecture that the
+ones the project is targeting (e.g. x86-64 vs aarch64). This means this environment relies on the assumption that code
+is portable and behaves architecture and compiler independent. This puts limitations on the features which can be tested
+and lower the confidence level of test output. In turn executing tests int his environment is simple and gives very good
+scalability options.
+
+--------------
+
+*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.*
+
+SPDX-License-Identifier: BSD-3-Clause
\ No newline at end of file