January 11, 2011 at 6:09 am
I suspect there are a few laws that already affect us, which aren't being fully obeyed, but I'm curious which apply. We don't store medical information or credit card info, but I have seen social security numbers occasionally. Names and addresses are definitely stored here.
January 11, 2011 at 6:56 am
I suspect that before anyone can answer that question you're going to have to say where your company is based. The applicable laws in the country I live in are going to be very different from laws in Europe, laws in the USA (and there likely will be different by state), laws in Australia, etc.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 11, 2011 at 7:07 am
My company of about 350 employees is in California, USA. Our parent company is based in Connecticut. The company that just bought our parent and us is based in the state of New York. We do business in many states. This probably just illustrates the need for a comprehensive Federal law.
Actually I think all three are traded on the NASDAQ exchange so it may be more of a question about which laws already apply and may or may not be adhered to. I know we don't encrypt our databases, although much traffic between our customers and us is over secure ftp.
January 11, 2011 at 10:11 am
The majority of laws for businesses come from three places these days. OSHA, HIPPA, and SEC.
When you say security laws, do you mean *trading* securities (stocks, bonds, options), or physical security like the rent-a-cop at the door?
The laws here really don't change much if you're public or private except for what the SEC imposes. Most of the SEC's rules are wrapped around shutting down insider trading. The rest... well... if you wanted to publically host your address list, you could. Your customers would hate you as every spam bot and letter writer in the world ripped it, but you could.
HIPAA is the only one of the triumverate that really does any significant personal data protections, other than the Do Not Call list stuff. The big thing with HIPAA is that you can't track back a person to a medical issue. It needs to stay as confidential as possible, preferably doctor/patient only. You can assign random GUIDs to people though and toss them around all day.
This, however, has nothing to do with going from private to public. This is just the law, period.
There are no significant data laws (in the U.S.) that change during an IPO.
Of course, final note, my disclaimer: I AM NOT A LAWYER. WHAT I SAY HAS NO PROFESSIONAL BEARING AND IS CONSIDERED HEARSAY AND AMATEUR. CHECK ALL FINDINGS WITH A REGISTERED LAWYER OF YOUR LOCAL STATE BAR BEFORE PROCEEDING LEGALLY ON ANY MATTER DISCUSSED.
There, that should Cover my ...
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 11, 2011 at 10:44 am
Pre disclaimer: I am not a lawyer and I haven't stayed at a Holiday Inn Express recently..
The law that comes to mind immediately is SOX. From the IT side SOX demands a fair degree of change control and auditing. So if you make changes willy nilly now on your production systems without much or any oversight I would forsee that changing. When SOX came into being I was working for a publicly traded company and a Change Authorization Board (CAB) was created, all changes to production went through this board. The other thing was that changes to production systems that could be scripted SHOULD be scripted.. Changing a table, generate a script! This was done mainly so that the change script itself could be stored with the request. Even production roll-outs were CAB'd, but the changes were not generally included in the change log, just a list where it was possible.
I guess where I'm going with this is that production system changes are logged and approved and that many things aren't allowed without a change authorization.
Also, your change control process will be audited and compliance measured, make sure you have someone who knows the process intimately explain it to the auditors.
Also, monitoring tools will likely be expected, either purchased or home-built. The auditors will want to compare changes MADE to changes AUTHORIZED.
Expect the first round to be rough if this is a change in your culture.
I would caution against going overboard on the rules for production changes, I have seen a couple environments that almost any change no matter how minor results in a change request, these environments were problematic to manage and lead to high turnover. As a base for databases:
1. Server restarts (machine or SQL), basically anytime SQL won't be responding to clients.
2. New/Changed Objects, ie: sprocs, tables, views, indexes, functions, synonyms, SSIS/DTS packages etc.
3. New/Changed Application related SQL Agent jobs, jobs related to system maintenance are excepted.
4. Security changes, new logins/users/roles, generally handled through a different change system than the other items here, for timeliness reasons.
5. Creation or attachment of a database.
6. Any change that makes a database unavailable.
7. Application database data changes (I/U/D)
Things that shouldn't require a change:
1. Database backups of any type.
2. Traces
3. Execution of sprocs, even if they change data - some exceptions
4. Re-Indexing
5. Admin database data changes (I/U/D), these are typically tied to DBA admin and monitoring activities and are therefore the DBA's to manage as they see fit.
There are other things but these are the big ones I thought of first.
Also, many private companies chose to comply with all or part of SOX even though they weren't *required* to because there are some good practices and it doesn't hurt to say that we are generally SOX compliant already if we are looking to sell..
CEWII
January 11, 2011 at 10:57 am
^ Elliott's right. I blame it still being morning, sorry... and I was thinking of data security and protection in a different light.
I live and breath SOX so often I forget it's actually a law. One comment though. While you might not need a change script for administrative data changes, you do need an audit of who did what. The audit level will allow you to avoid needing authorizations and permissions.
If you don't have one, you will need the other, if you need to be SOX compliant.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 11, 2011 at 11:16 am
Completely agree, know what changed and who changed it are very important.
How often have you asked what changed? And everybody looks at you like you are a mutant.. Something changed, and *I* didn't do it, so who did?
Not sure if it is part of the law, but the requestor, the do'er, and the verifier cannot all be the same person, but one person can fill 2 roles. It is better if the do'er and the verifier are different..
CEWII
January 11, 2011 at 12:48 pm
Great checklist there Elliot. We do have change control. And annual SAS70 audits. It appears that many of the laws aren't actively enforced until you have a problem discovered by a client.
January 11, 2011 at 1:11 pm
Indianrock (1/11/2011)
Great checklist there Elliot. We do have change control. And annual SAS70 audits. It appears that many of the laws aren't actively enforced until you have a problem discovered by a client.
I'm not sure they aren't enforced, but you need to be able to show due dilligence and a process framework that is in place and actively being used. If you have an investigation go on and you can't show that it is bad. They might say that your process isn't very strong, but we have to operate in the real world and theoretical best practices often fail in that reality or are far too costly to implement. Case in point, small shops often won't implement MS best practices for drive layouts for SQL, because they don't have the $$$$ for a big SAN or a huge disk cage for every SQL server. Are they negligent? No! The real world interfered with what is "best" and they did the best with what they had. Due dilligence and best efforts..
I am unsure what SAS70 audits cover but if you are already operating with some(many?) of the SOX rules then the movement into a SOX compliance required environment won't be so painful. As I said, many private companies seek to largely comply simply because the rules make sense. They usually don't get too militant about it though since compliance is voluntary for them and no fines are possible for non-compliance.
CEWII
January 11, 2011 at 2:05 pm
The problem of complying with laws in multiple states reminds me of how the SEC and other regulatory bodies failed in regulating Wall Street. A domestic-only focus is inadequate in a multi-national world.
Now for my anti-states-rights rant. Is there any more reason for states to create their own data security laws than there would be for states to each determine the guage ( width ) of railroad tracks entering their borders? 🙂
January 11, 2011 at 2:15 pm
Indianrock (1/11/2011)
The problem of complying with laws in multiple states reminds me of how the SEC and other regulatory bodies failed in regulating Wall Street. A domestic-only focus is inadequate in a multi-national world.Now for my anti-states-rights rant. Is there any more reason for states to create their own data security laws than there would be for states to each determine the guage ( width ) of railroad tracks entering their borders? 🙂
Heh, a bit broad there. The more likely association there is why should each state decide the TCP/IP protocol standards.
It was there to keep the majority of laws out of the hands of the feds and in the hands of smaller groups of people who could make up their local preferences instead of having to all be under one umbrella. It worked better back then when a few hundred thousand people was a lot...
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 11, 2011 at 2:23 pm
Very true.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply