GeekyDad

There is definitely a crisis looming, based on my experiences to date. What I have seen over the last few years in schools is a million miles away from the requirements of the GDPR regime that comes into being in May: very poorly drafted privacy notices, implied consent/opt-in by default, little/no breach reporting, poor contracts with suppliers, no supplier due diligence, little understanding of who data is shared with externally, over-sharing of sensitive data (e.g. ethnicity). Despite a 2 year run-up, most organisations I have dealt with, schools included, will not be ready to face the harsh reality of GDPR in May: - co-liability between controllers & processors - mandatory breach reporting - fines for administrative breaches not just data loss - consent must be explicit, freely given, auditable & informed i.e. no assumed consent The big change that has been under-reported is the ability of data subjects to claim compensation for 'distress' following a GDPR breach - which can be administrative with no actual data loss and no actual harm for the data subject. This is the next PPI in my opinion. Given that most schools send out privacy notices in September at the start of the school year, which has already passed, there is a lot of work to do prior to May in terms of consent from pupils/parents/guardians. There is no scope for opting in by default unlike at present. In cases where 'personally identifiable information' (PII) is shared externally - such as extracts out of an MIS like SIMS - unless there is a legal requirement to do so, it seems likely that each and every pupil record that leaves the premises will require explicit consent. Any other basis for non-mandated PII data sharing brings the very real risk of a fine for both the controller and the processor, and opens the door for compensation claims from the data subject - in this case the pupils. For a bit of perspective, consider the fact that JD Wetherspoons have binned their marketing database as the risk is too high to warrant using it come next May: Wetherspoons just deleted its entire customer email database ? on purpose | WIRED UK Schools simply can't afford to run the risk of a fine under GDPR. My advice is quite simple - current data processing/sharing activities should only persist beyond May if legally required. Anything else runs the risk of a large fine, which schools can ill afford. Arguing 'public interest' or 'essential processing' is a very risky strategy in all but a few very specific cases. Externally provided whizzy analytics or MI will require explicit consent from every data subject. Good luck with that!

One of the biggest changes concerns data sharing. Consent will have to be explicitly obtained on a case by case basis with a detailed consent audit log maintained. Default, assumed or blanket opt-in to data sharing will no longer be allowed under GDPR.

@pcstru - I'd be interested in your definition of 'cripple' when it comes to a database, and also how this state can be achieved with select queries. If you are unfortunate enough to run a product join by accident simply kill the query. You *will not* do any harm to the underlying tables, no matter how hard you try. Call MS and ask how many times a select query has corrupted data in SQL Server. SQL queries can and should be developed against a 'production' system, if there is a need to do so. SIMS runs schools, not banks. There simply isn't a high enough level of transaction activity for data input & SQL queries to conflict with each other. Don't believe me? Check out the average CPU busy on your server. Low isn't it? FYI, banks run SQL queries against production systems, as do all big companies. Resource demand conflicts (mainly CPU) between transaction processing & queries is the main reason they try not to, not any notion of risk. Schemas can be de-mystified quite readily if you are willing to put in a bit of effort. There are rare cases where schemas has been intentionally obfuscated, but these are few and far between. Start with the biggest tables and go from there. The model normally reveals itself quite quickly, even in cases with >1,000 tables. It shouldn't take more than a day to understand the core entities and how they relate together, so long as you are a reasonably experienced database developer. If there are PK:FK relationships specified a visual model can be generated very quickly. @matt40k - you can run analysis reports against 'your transactional production system'. All production systems in all companies have operational reporting built in, including SIMS. Imagine not being able to run a report/query until someone built a data warehouse... What does 'smash your indexes' mean? Sounds exciting ;-) Building a data warehouse is an elective pursuit. You *do not* need to build copies of your transactional data for reporting purposes, unless reporting against the transactional system is not possible for some reason (and there are several). There are simply no barriers/risks to running SQL queries directly against SIMS. What's the biggest row count in a single SIMS table? That's right...miniscule. If anyone does want an analytic copy of their SIMS data in the cloud on SQL Server just let me know. Rather than take your money I'd point you back at SIMS and tell you to run your queries there...unless you can show me with *evidence*, and not emotive language, that it's a bad idea.

Fair point. Schools should collaborate on this & share SQL queries. No point in all re-inventing the wheel. In the new landscape of teaching actual *computing* & not ICT, it seems reasonable thats schools as a whole should raise their game when it comes to knowing how to run SQL queries against a product as widely used as SQL server. These are very useful skills within and outside the education sector.

'Hugely frowned upon' is not the same as 'you will break it if you try'. You won't. Just use a 'read only' userid. You *will not* break SQL Server by running queries against it. Not unless you know how to! Not using a DBMS to do what it's been built for - by the world's largest software company - & sending sensitive data offsite to do a limited set of what's possible locally makes no sense to me...especiaily if you have to pay for the privilege.

There's no reason in the world you shouldn't run SQL queries against the SIMS database. It's SQL Server. That's what it's for. The clue is in the name ;-) Just make sure you use a read-only 'report user' that you create specifically to run queries. Alternately, make sure you know what you're doing. SELECT = safe. UPDATE/DELETE/INSERT = not safe!

Sharing personal data is more of a compliance issue than a technical issue. There is guidance from the ICO here: https://ico.org.uk/for-organisations/guide-to-data-protection/data-sharing/ Sensitive data (which includes ethnicity) is subject to extra requirements: https://ico.org.uk/for-organisations/guide-to-data-protection/conditions-for-processing/#conditions-sensitive-data The ICO's 12 step guide to GDPR compliance (Brexit notwithstanding) offers guidance on upcoming data protection/security obligations: https://ico.org.uk/media/for-organisations/documents/1624219/preparing-for-the-gdpr-12-steps.pdf The obligations around consent are particularly relevant. Full end-to-end encryption of all shared data seems to be a minimum desirable standard. Interesting debate on data abuse recently caught the eye: Jail data abusers says Culture, Media and Sport Committee report - News from Parliament - UK Parliament