Lawful Basis: Legal Obligation

The legal obligation is applicable as a lawful basis when it is necessary to process personal data to comply with a common law or a statutory obligation. In this case, there must be a specific legal provision or an appropriate source of advice or guidance that clearly sets out the obligation.
This does not apply to contractual obligations and it does not apply when it is reasonably possible to achieve the same goal without processing the personal data.
As always, the action should be documented for justification about the why and how the personal data was gathered and processed.

When is it Applied?

It is applied when an organization is obliged to process the personal data to comply with the law.
Be aware that Recital 41 confirms that this does not have to be an explicit statutory obligation, as long as the application of the law is foreseeable to those individuals subject to it. So it includes clear common law obligations.

In a simple and straightforward way, it is applied whenever a state member or EU law enforces it because the overall purpose is to comply with a legal obligation which has a sufficiently clear basis in either common law or statute.

Obviously, it requires the identification of the obligation in question, either by reference to the specific legal provision or else by pointing to an appropriate source of advice or guidance that sets it out clearly. For example, you can refer to a government website or to industry guidance that explains generally applicable legal obligations.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

Lawful Basis: Contract

There is a lawful basis for personal data processing when the personal data of an individual is required to fulfill a contract obligation or when the individual asks an organization to do something before entering in a contract.
This does not apply when it is reasonably possible to achieve the same goal without processing the personal data.
As always, the action should be documented for justification about the why and how the personal data was gathered and processed.


When the personal data processing is required for a contract with an individual, a separate consent is not required.
This is quite simple and straightforward.

When in a special category data is necessary for the contract, then it is also required to identify a separate condition for processing this data.

When the contract is with a child under 18, the organization must consider whether they have the necessary competence to enter into the contract. When in doubt, another lawful basis could be applied, for instance, legitimate interests if it demonstrates that the child’s rights and interests are properly considered and protected.


When personal data is being processed on the basis of contract, the individual’s right to object and the right not to be subject to a decision based solely on automated processing does not apply. However, the individual has the right to data portability.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

Basis for Personal Data Processing

GDPR enforces organizations to have a valid lawful basis in order to process personal data.
There are six lawful bases, all equal in importance, though the selection of which basis is the most appropriate to use will depend on the organization purpose and its relationship with people.

The lawful basis must be determined before the data processing begins because it should be documented along with the purposes of the data processing, and included in the privacy notice accepted by the individuals. This makes it clear for the people to know what they are consenting.

If the purposes change, unless it is compatible with the initial purpose, it will require a change of the lawful basis, and it could be necessary to redo the processes of documentation, consenting, etc..

Lawful Bases for Data Processing

The six lawful bases for personal data processing are defined in Article 6:

  • the data subject has given consent to the processing of their personal data for one or more specific purposes;
  • processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
  • processing is necessary for compliance with a legal obligation to which the controller is subject;
  • processing is necessary in order to protect the vital interests of the data subject;
  • processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;
  • processing is necessary for the purposes of the legitimate interests pursued by a controller, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. This shall not apply to processing carried out by public authorities in the performance of their tasks.

Processing activities that fall under performance of a contract, legal obligation, vital interests and public task may be fairly straight-forward to identify. The key for many will be assessing whether Consent or Legitimate Interests will be most appropriate for specific processing of personal information.

Processing Special Category Data

When processing special category data organizations need to identify both a lawful basis for the general processing and an additional condition for processing this type of data.

Criminal Data Processing

When processing criminal conviction data, or data about offenses, it is necessary to identify both a lawful basis for general processing and an additional condition for processing this type of data.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

GDPR Principles

The GDPR define the main responsibilities for organisations when it comes to data protection and personal data processing.

Article 5 of the GDPR introduces the two pillars of the personal data protection and processing. Putting it simply, it introduces the data related principles and who is responsible for enforcing it.

Data Principles

Under GDPR, personal data shall be:

  • processed lawfully, fairly and in a transparent manner in relation to individuals;
  • collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall not be considered to be incompatible with the initial purposes;
  • adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed;
  • accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay;
  • kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes subject to implementation of the appropriate technical and organisational measures required by the GDPR in order to safeguard the rights and freedoms of individuals;
  • processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.

As seen above, there are specific situations where the data protection and processing principles have been, somewhat, extended.
For such cases, safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes are introduced in Article 89.


Under GDPR, a controller is required and shall be

be responsible for, and be able to demonstrate, compliance with the principles.

In short, organisations now have a Data Protection Officer (commonly known as DPO) that has the responsible for, and be able to demonstrate compliance with, the data protection in accordance with GDPR, becoming accountable for its compliance.

Depending on the size of the organisation, DPO can be someone from the organisation itself, except someone from the organisation administration, for obviously possible conflict of interests.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

What is GDPR?

GDPR stands for General Data Protection Regulation and, legally, it’s the EU 2016/679 regulation about protection of personal data.

GDPR defines the rights and obligations regarding the gathering, processing and movement of EU citizens personal data. It provides a high and coherent protection level, equivalent in all member states, and is extensible to external EU organizations that work with EU citizens personal data.

The obligations related to the manipulation of personal data now cover things like the right to be forgotten and organizations are now obligated to inform the regulator when they have a personal data breach.

So, what is “personal data”?

In a simple way, it’s all the data about a person that an organization collects, stores and transmits: web forms, cookies, user preferences, medical reports, receipts, etc.. GDPR enforces the lawful, fair and transparent processing of the personal data in relation to the data subject.
In the GDPR legislation, personal data is defined as

any information relating to an identified or identifiable natural person (“data subject”); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity

Check Article 4 for detail.

How about highly sensitive data?

GDPR takes into consideration special types of data that are highly sensitive, such as health, criminal convictions, sexual life, political, genetical, etc.. In such cases, special rules are applicable.

Check Article 9 for detail.

Who does this applies to?

This applies to all people and organizations that collect, gather, transmit or process in any way European Union citizens personal data. Yes, this means that non-EU organizations must comply with this regulation when dealing with EU citizens.

Micro, small and medium-sized organizations have a somewhat relaxed compliance levels. It includes a derogation for organizations with fewer than 250 employees with regard to record-keeping.

Public and criminal law organizations are covered by special rules since they address specific national and European issues.

How hard is it for me to comply with GDPR?

As it’s obviously understandable, it will depend on how big your organization is, what it does and how it already addresses the personal data processing.

The best map road for compliance starts with an assessment performed by a multidisciplinary team composed by GDPR certified people, GDPR knowledgeable lawyers and a pragmatic IT team that truly understands GDPR.

Get in touch with us if you need help on the subject.

DB2 copy schema with tables

Sometimes one needs to automate a DB2 schema copy, clone or simple backup.
If the requirements are just to create a new schema and copy the tables and their content into the new schema, it seems to be a simple task.
But this simple task soon reveals to be a hard one, which can be achieved with a quite simple script.

The first step is to created a specific schema for this automation task, e. g. COPY_DATABASE_SCHEMA, so all the procedures will be created there.

The procedure that copies the table content is easy to code. Just declare a cursor that selects the source table data and load it into the target table.
Here is the procedure that performs the copy of the table content:

* Copies, with replacement, the content from the source table
* into the target table.
* It will not check for success, i.e. no loading validation
* will be performed.
* @sourceTable: the full qualified source table name
* @targetTable: the full qualified target table name

sourceTable VARCHAR(128),
targetTable VARCHAR(128))
DECLARE v_version_number INTEGER DEFAULT 1;
DECLARE v_cursor_statement VARCHAR(32672);
DECLARE v_load_command VARCHAR(32672);
DECLARE v_sqlmessage VARCHAR(2048) DEFAULT '';
DECLARE v_rows_skipped BIGINT DEFAULT -1;
DECLARE v_rows_loaded BIGINT DEFAULT -1;
DECLARE v_rows_rejected BIGINT DEFAULT -1;
DECLARE v_rows_deleted BIGINT DEFAULT -1;
DECLARE v_rows_committed BIGINT DEFAULT -1;
DECLARE v_rows_part_read BIGINT DEFAULT -1;
DECLARE v_rows_part_rejected BIGINT DEFAULT -1;
DECLARE v_rows_part_partitioned BIGINT DEFAULT -1;
DECLARE v_mpp_load_summary VARCHAR(32672) DEFAULT NULL;

SET v_cursor_statement =
   'DECLARE C1 CURSOR FOR SELECT * from ' || sourceTable;
SET v_load_command =
   'load from C1 of cursor insert into ' || targetTable;

CALL db2load(1, v_cursor_statement, v_load_command, v_sqlcode,
         v_sqlmessage, v_rows_read, v_rows_skipped,
         v_rows_loaded, v_rows_rejected, v_rows_deleted,
         v_rows_committed, v_rows_part_read,
         v_rows_part_rejected, v_rows_part_partitioned,
         v_mpp_load_summary) ;

Please note that the target table must already be created in order for this procedure to work, and the script terminator is # and not the usual ;.

This procedure is the hardest part of the script. Copying the contents of any table requires a dynamic prepared query statement to use as a cursor, and the load command is not available inside a procedure, so the db2load procedure from SYSPROC must be used.

The next procedure creates the schema, the tables, and copies the tables contents:

* Copies an entire schema into a new schema named with the current date.
* @sourceSchema: the source schema name
* @targetSchema: the target schema name
* @tableNameSelection: the tables name to include ('%' for all tables)

sourceSchema VARCHAR(50),
targetSchema VARCHAR(50),
tableNameSelection VARCHAR(150)
-- Variables
DECLARE stmtSchema VARCHAR(250);
DECLARE stmtTableStructure VARCHAR(200);
DECLARE stmtTableContents VARCHAR(250);
DECLARE stmtAlias VARCHAR(250);
DECLARE tableName VARCHAR(128);

-- Create schema
SET stmtSchema = CHAR('CREATE SCHEMA ' concat CHAR(targetSchema));

-- Copy tables and views
       WHERE CREATOR = '
'' || TRIM(sourceSchema) || '''
       AND NAME LIKE '
'' || TRIM(tableNameSelection) || '''
       order by name'

FETCH TGT_TABLE_CUR INTO tableName, numPages;
IF at_end <> 0 THEN
  LEAVE fetch_loop;
  SET stmtTableStructure = 'CREATE TABLE ' ||
      targetSchema || '.' || tableName || ' LIKE ' ||
      sourceSchema || '.' || tableName ;
  EXECUTE IMMEDIATE stmtTableStructure;

  IF numPages > 0 THEN
             sourceSchema || '.' || tableName,
             targetSchema || '.' || tableName);
END LOOP fetch_loop;


It dynamically issues DB2 SQL commands to create the schema and the tables structure and makes use of the previously created COPY_TABLE to copy the tables content. See the code comments for more information.

To use this just

CALL COPY_DATABASE_SCHEMA.COPY_DATABASE('sourceSchemaName','targetSchemaName','%');

These procedures have some limitations, for instance views are not supported.
Nevertheless, it is a good start to all that need to clone a schema or a table, since all the missing items can be gathered from the database catalog.

If you to drop an old schema, for instance to recreate it with a a new updated version, you can drop drop the schema with this procedure.