diff --git a/process/Sql_lib/documentation.adoc b/process/Sql_lib/documentation.adoc
index ba5d6eb3c4dd933e06df3d2c748e50136c4b875c..a036b8325eaefe0b93042777ce96bf52e8f5e14b 100644
--- a/process/Sql_lib/documentation.adoc
+++ b/process/Sql_lib/documentation.adoc
@@ -28,11 +28,10 @@ The tests included in the library SqlLib_tests use the UnitTest_lib for unit tes
 
 The SQL builder applies Prepared Statements (if used correctly). These should *always* be used for reasons of
 
-* *Security* (prevention of "SQL injection" see also `AID068`):
-This is the *most important* aspect.
+* *Security* (main benefit):
 In SQL statements like 
 `"select * from PERSON where FIRSTNAME = '" + userInput + "'"`
-the user could input also any - possibly harmful - SQL code. This will be avoided by using Prepared Statements: Even if you just select for IDs, the security and the quality of your code will be much higher. Because you are used to using Prepared Statements and won't forget them when they are really needed. (e.g. direct user input)
+the user could input also any - possibly harmful - SQL code ("SQL injection" see also `AID068`). This will be avoided by using Prepared Statements: Even if you just select for IDs, the security and the quality of your code will be much higher. Because you are used to using Prepared Statements and won't forget them when they are really needed. (e.g. direct user input)
 * *Speed*: If the server executes a Prepared Statement, the performance will, in many cases, be higher compared to executing a self-made SQL code.
 
 === Usability