diff --git a/xml/source/snippets/offerte/en/methodology_code-audit.xml b/xml/source/snippets/offerte/en/methodology_code-audit.xml
index 5530cf7..e86c7d1 100644
--- a/xml/source/snippets/offerte/en/methodology_code-audit.xml
+++ b/xml/source/snippets/offerte/en/methodology_code-audit.xml
@@ -2,56 +2,45 @@
 <section>
   <title>Code Audit</title>
   <p>
-    <company_short/>
-    will perform a code audit. During this process we will verify if the proper
-    security controls are present, work as intended and are implemented
-    correctly. If vulnerabilities are found, we determine the threat level by
-    assessing the likelihood of exploitation of this vulnerability and the
-    impact on the Confidentiality, Integrity and Availability (CIA) of the
-    system. We will describe how an attacker would exploit the vulnerability and
-    suggest ways of fixing it.
-  </p>
-  <p>This requires an extensive knowledge of the platform the application is
-    running on, as well as the extensive knowledge of the language the
-    application in written in and patterns that have been used. Therefore a code
-    audit done by highly-trained specialists with a strong background in
-    programming.
-  </p>
-  <p>
-    During the code audit, we take the following approach:
-  </p>
+    <company_short/> will perform a code audit. During this process we will verify if the proper
+    security controls are present, work as intended and are implemented correctly. If
+    vulnerabilities are found, we determine the threat level by assessing the likelihood of
+    exploitation of this vulnerability and the impact on the Confidentiality, Integrity and
+    Availability (CIA) of the system. We will describe how an attacker would exploit the
+    vulnerability and suggest ways of fixing it. </p>
+  <p>This requires an extensive knowledge of the platform the application is running on, as well as
+    the extensive knowledge of the language the application in written in and patterns that have
+    been used. Therefore a code audit done by highly-trained specialists with a strong background in
+    programming. </p>
+  <p> During the code audit, we take the following approach: </p>
   <ol>
     <li><b>Thorough comprehension of functionality</b>
-      <br/>
-      We try to get a thorough comprehension of how the application works and
-      how it interacts with the user and other systems. Having detailed
-      documentation (manuals, flow charts, system sequence diagrams, design
-      documentation) at this stage is very helpful, as they aid the
-      understanding of the application
-    </li>
+      <br/> We try to get a thorough comprehension of how the application works and how it interacts
+      with the user and other systems. Having detailed documentation (manuals, flow charts, system
+      sequence diagrams, design documentation) at this stage is very helpful, as they aid the
+      understanding of the application </li>
+    <li><b>Comprehensive code reading</b></li><br/> goals of the comprehensive code reading are:
+        <ul><li>to get an understanding of the whole code</li>
+      <li>identify adversary controlled inputs and trace their paths</li>
+      <li>identify issues</li></ul>
     <li><b>Static analysis</b>
-      <br/>
-      Using the understanding we gained in the previous step, we will use static
-      code analysis to uncover any vulnerabilities. Static analysis means the
-      specialist will analyze the code and implementation of security controls
-      to get an understanding of the security of the application, rather than
-      running the application to reach the same goal. This is primarily a manual
-      process, where the specialist relies on his knowledge and expertise to
-      find the flaws in the application. The specialist may be aided in this
-      process by automatic analysis tools, but his or her skills are the driving
-      force.
-      <br/>
-      Depending on the type of application, we will identify the endpoints. In
-      this case, it means where data enters and leaves the application. The data
-      is then followed through the application and is leading in determining if
-      assessing the quality of the security measures.
-    </li>
-
+      <br/> Using the understanding we gained in the previous step, we will use static code analysis
+      to uncover any vulnerabilities. Static analysis means the specialist will analyze the code and
+      implementation of security controls to get an understanding of the security of the
+      application, rather than running the application to reach the same goal. This is primarily a
+      manual process, where the specialist relies on his knowledge and expertise to find the flaws
+      in the application. The specialist may be aided in this process by automatic analysis tools,
+      but his or her skills are the driving force. <br/> Depending on the type of application, we
+      will identify the endpoints. In this case, it means where data enters and leaves the
+      application. The data is then followed through the application and is leading in determining
+      if assessing the quality of the security measures. </li>
     <li><b>Dynamic analysis</b>
-      <br/>
-      Dynamic analysis can also be performed. In this case, the program is run
-      and actively exploited by the specialist. This is usually done to confirm
-      a vulnerability and as such follows the result of the static analysis.
-    </li>
+      <br/> Dynamic analysis can also be performed. In this case, the program is run and actively
+      exploited by the specialist. This is usually done to confirm a vulnerability and as such
+      follows the result of the static analysis. </li>
+    <li><b>Fuzzing</b>
+    <br/> Fuzz testing or Fuzzing is a software testing technique which in essence consists of finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.</li>
+    <li><b>Concolic analysis</b>
+    <br/> If the specialist thinks it useful, additional concolic analysis may be performed on selected subsets of the code.</li>
   </ol>
 </section>
diff --git a/xml/source/snippets/offerte/en/projectoverview.xml b/xml/source/snippets/offerte/en/projectoverview.xml
index 6c21fd1..8f45ea7 100644
--- a/xml/source/snippets/offerte/en/projectoverview.xml
+++ b/xml/source/snippets/offerte/en/projectoverview.xml
@@ -19,7 +19,8 @@
     <company_short/> will test for the presence of the most common
     vulnerabilities, using both publicly available vulnerability scanning
     tools and manual testing. <company_short/> shall perform a
-    <p_duration/>-day (<p_persondays/>-personday), <p_boxtype/>, intrusive test via the
+    <p_duration/>-day (<p_persondays/>-personday) 
+    <p_boxtype/> intrusive test via the
     internet.
   </p>
 
diff --git a/xml/source/snippets/offerte/en/projectoverview_code-audit.xml b/xml/source/snippets/offerte/en/projectoverview_code-audit.xml
new file mode 100644
index 0000000..da1fd4c
--- /dev/null
+++ b/xml/source/snippets/offerte/en/projectoverview_code-audit.xml
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section>
+    <title>Project Overview</title>
+    <p>
+        <company_short/> will perform a <company_svc_long/> of the source code files described below
+        for <client_short/>. The code audit is intended to gain insight into the security of the
+        source code. To do so, <company_short/> will analyze the code, attempt to find
+        vulnerabilities, and gain further access and elevated privileges by exploiting any
+        vulnerabilities found. </p>
+
+    <p>
+        <company_short/> will test the following code (the “<b>Targets</b>”): </p>
+
+    <generate_targets/>
+
+    <p>
+        <company_short/> will test for the presence of the most common vulnerabilities using a
+        combination of publicly available (static, dynamic and concolic) analytic tools, fuzzing and
+        code reading. <company_short/> will perform this code audit in <p_duration/> days
+        (<p_persondays/> persondays). </p>
+    
+
+    <!--Not Needed if Disclaimer is Included; Duplicate Text-->
+    <!--p>It is possible that in the course of the penetration
+  testing, <company_short/> might hinder the operations of the Targets or
+  cause damage to the Targets. <client_short/> gives permission for this, to
+  the extent that <company_short/> does not act negligently or
+  recklessly. <client_short/> also warrants it has the authority to give such
+  permission.</p-->
+
+    <!--Not Needed if Disclaimer is Included; Duplicate Text-->
+    <!--p>It is important to understand the limits of
+  <company_short/>'s services. <company_short/> does not (and cannot)
+  give guarantees that something is secure. <company_short/> instead has
+  an obligation to make reasonable efforts (in Dutch:
+  “<i>inspanningsverplichting</i>”) to perform the agreed services.</p-->
+
+    <!--REMOVE commented-out text above if not including Disclaimer-->
+</section>
diff --git a/xml/source/snippets/snippetselection.xml b/xml/source/snippets/snippetselection.xml
index 7ed2542..b7ec30f 100644
--- a/xml/source/snippets/snippetselection.xml
+++ b/xml/source/snippets/snippetselection.xml
@@ -89,7 +89,7 @@
       <!-- no additional code audit presumed :) -->
       <snippet_group set="group1">
         <snippet>introandscope</snippet>
-        <snippet>projectoverview</snippet>
+        <snippet>projectoverview_code-audit</snippet>
         <snippet>prerequisites</snippet>
         <snippet>disclaimer_code-audit</snippet>
         <snippet>methodology_code-audit</snippet>