Your site certificate (+ private key) should be treated like any site certificate. If someone was to get hold of the private key, they would be able to impersonate your website. There is little difference in the way you would have to trust the hosting service for a certificate issued by a commercial CA.
The risks here are mitigated by the fact that, since you've created your own CA, few people will trust that CA by default. It's a risk that's effectively limited to those who've opted in to trust your CA.
The same applies to the CA private key. Someone who gets hold of its private key could issue any certificate.
The biggest problems comes from the fact that user interfaces tend to treat all trusted CAs equally (unless EV certs), or very similarly if the user doesn't pay attention. As a result, if an attacker (a) had your CA's private key and (b) knew a user who trusts this CA cert to target, they could create a certificate valid for any website they want.
Your risk assessment should take into account who will opt in to trust this in-house CA. Commercial CAs tend to have strict policies regarding the protection of their private keys (typically, non-extractible storage on smart-cards or similar): this is often a requirement to be approved for inclusion in most browsers.
More specifically about "other pieces of information". It may be important, when designing a CA, to have a policy regarding what attributes and how Subject DNs are structured for example. I have known some CAs that made a point never to disclose the user's identity explicitly in the certificate (which is usually public and often visible during the handshake to an eavesdropper), so the Subject DN was just an internal ID, known to the CA (and possibly tied up to an actual name between the service and the CA by an encrypted back channel or similar mechanism).
